How to retain user security rules when transitioning from Windows authentication to Azure AD?

[kwdaniels]

We've been using Windows/LDAP authentication for several years but are wanting to transition to Azure AD authentication using the approach outlined in this tutorial.

We've proved out this approach in a dev environment, but we're disappointed that in the process, new users are created, which means we'll lose all the security rules and license allocations for our existing users.

See the attached screenshot showing my original user entry (Name: Ken Daniels; directory: CONTOSO) and the new user entry that was created after the first time I logged in using Azure AD (Name: ken.daniels@contoso.com; directory: AZURE). I had to manually assign my new user a role and a license allocation.

Is there a straightforward way to retain our existing users, allocations, and security rules, or do we have to start all over from scratch?

That's our primary concern. A secondary concern is that when setting up the Azure AD SSO/SAML authentication, we were required to define a prefix (we chose "sso"), which necessitated a change in url: whereas our previous url was https://qlik.contoso.com, it's now https://qlik.contoso.com/sso. This means all our direct links and bookmarks pointing to various sheets will be broken--not a pleasant experience. Is there any way to retain the original url after transitioning to Azure AD SSO?

[Levi_Turner · Accepted solution]

Primary question:

Ultimately you will want to match the userDirectory and userIds between the two authentication providers.

userDirectory is easy: QMC > Virtual Proxies > Edit Authentication > SAML Attribute for user directory. If you have a single AD, then just wrap the NETBIOS name of the domain (in this example CONTOSO) in brackets ([CONTOSO]). If you have varying ADs then use the same approach as the userId.

userId is a bit more complicated. At the outset, you should first review the attributes which are being sent. I regularly use this extension for Chrome, but there are similar ones for other browsers. After looking over the attribute statement, find if just plain vanilla userId is being sent as an attribute currently. If so, swap it out for the SAML Attribute for user ID section for the virtual proxy.

I don't have an Azure AD SAML virtual proxy setup, but to use an analogy to my Auth0 virtual proxy, my attributes are like so:

If I wanted to use just the portion before the @, then I'd use the nickname attribute and the value I'd enter into Qlik Sense is http://schemas.auth0.com/nickname (the value for the name element is how you tell Qlik Sense what to parse).

If there isn't an attribute present, then that means adding in on the SAML side and I don't have a doc ready made for that though from this guide (https://community.qlik.com/t5/Technology-Partners-Ecosystem/Azure-AD-Single-Sign-on-SAML-Over-an-App...) it looks like this is done when configuring Azure AD.

For the secondary concern,

• Add a prefix to the Windows virtual proxy (e.g. windows)
• Access the QMC using the new Windows virtual proxy prefix (e.g. analytics.company.com/windows/qmc)
• Remove the prefix for the SAML virtual proxy
• Make any adjustments to the SAML config

[kwdaniels]

Thanks, Levi! Earlier this morning, before your reply came in, I did some experimenting and came up with basically the same solution. I'll rehash it here with screenshots for those who'd like to see the context.

The main idea, as you expressed, is to make the user directory and user name for the SAML authentication match the directory and name for the existing Windows-authenticated users.

It was straightforward to set the directory; it was a matter of changing the "SAML attribute for user directory" from [AZURE] (as recommended in the tutorial) to our user directory name, [CONTOSO]:

To change the username format from an email address to firstname.lastname to match our existing Qlik usernames, I experimented with a number of different options for the "Name" in the screen below, logging out/in with an anonymous browser until I found one that worked: "onpremisessamaccountname":

After making these two changes, the new SAML username/directory combinations matched the old Windows ones (firstname.lastname), and it didn't create a second copy of the user, which satisfied our primary concern.

As for our secondary concern of preserving the same url as before, I followed your general approach and got it to work, so I'm very happy. Note, however, that after I set the prefix of the central virtual proxy to "windows", I was NOT able to log in with the /windows prefix. However, I was still able to log in under the secondary SAML virtual proxy I had already established with the /sso prefix, and then I was able to remove the sso prefix and then log in without a prefix. Phew!

Thanks again!

[Levi_Turner]

Perfect!

On the /windows virtual proxy, I would look into that guy to get it to work since it is leveraged by the License and Operations Monitor apps for reload. They will likely fail. Although the log signature isn't the same as this issue the fix would be the same (switch the URL to use the Windows virtual proxy). Likewise, a lot of the higher end monitoring and performance optimization apps assume the underlying data connections which are leveraged by the License and/or Operations Monitor apps are setup and good to go (for example, this app)

[kwdaniels]

Thanks, Levi. I just now tried logging in using the /windows prefix, and this time it let me in! Not sure why it didn't work earlier; maybe there was some sort of configuration delay.

However, based on your mention of the License and Operations Monitor apps, I decided to take a look at the task log and found that it's been failing. I'm including the relevant portion of the log below; are you able to tell what could be causing this? It last succeeded this morning before I added the /windows prefix to the central virtual proxy.

2019-07-17 19:56:35 0664 LIB CONNECT TO 'monitor_apps_REST_license_user'
2019-07-17 19:56:36 Connected.
2019-07-17 19:56:36 0665 trace connect to monitor_apps_REST_license_user
2019-07-17 19:56:36 0665 connect to monitor_apps_REST_license_user
2019-07-17 19:56:36 0666
2019-07-17 19:56:36 0667 user_map:
2019-07-17 19:56:36 0668 Mapping LOAD
2019-07-17 19:56:36 0669 [__FK_user]&'user' as key,
2019-07-17 19:56:36 0670 userDirectory & '\' & userId as UserId
2019-07-17 19:56:36 0672 SQL SELECT
2019-07-17 19:56:36 0673 (SELECT
2019-07-17 19:56:36 0674 "id",
2019-07-17 19:56:36 0675 "userId",
2019-07-17 19:56:36 0676 "userDirectory",
2019-07-17 19:56:36 0677 "__FK_user"
2019-07-17 19:56:36 0678 FROM "user" FK "__FK_user")
2019-07-17 19:56:36 0679 FROM JSON (wrap on) "root" PK "__KEY_root"
2019-07-17 19:56:36 2 fields found: key, UserId,
2019-07-17 19:56:36
2019-07-17 19:56:36 Unexpected character encountered while parsing value: <. Path '', line 0, position 0.
2019-07-17 19:56:36 Error: Unexpected character encountered while parsing value: <. Path '', line 0, position 0.
2019-07-17 19:56:36 Unexpected character encountered while parsing value: <. Path '', line 0, position 0.
2019-07-17 19:56:36 Execution Failed
2019-07-17 19:56:36 Execution finished.

One final matter: I tried accessing the Engine API through the .NET SDK using the following endpoints:

• https://dev-qlik.parivedasolutions.com:443/windows
• https://dev-qlik.parivedasolutions.com/windows
• https://dev-qlik.parivedasolutions.com:443

However, I'm getting this error:

• Engine at https://dev-qlik.contoso.com/ is not alive

Is there something special we need to do to configure the license monitoring app and engine API to work with the /windows central proxy?

[Levi_Turner]

For the first, that suggests the /windows virtual proxy has Forms configured. Is that the case? If so, then the REST Connector cannot programmatically interact with a webpage. So the above article would be the route to go if you want to keep forms.

Or that the path being called for the data connections is https://localhost/qrs/... or https://server.company.com/qrs/.... Now that you've swapped to have the SAML virtual proxy as the prefixless virtual proxy, you'd want to adjust the path being called by the REST Connector to the virtual proxy with vanilla Windows authentication. The above article should point you in the right direction.

For the later issue, I am lighter on the Engine API in general and a .NET SDK integration in particular. I suspect spawning a new thread on the Integrations forum with code examples, etc would be appropriate.

[kwdaniels]

Update: 

Adding the "/windows" prefix after "localhost" in the "monitor_apps..." data connections solved the problem with the loading of the license and operations monitors.

I submitted a separate post on the Engine API connection issue and received a helpful response here.

Now all our open issues are resolved and we're good to go!

Thanks so much again for all your help, Levi.

Ken

[Riddhi1]

Hi All,

We are also facing issue of duplicate users when logged in through SAML.

Issue is since different users are belonging to different domains passing one domain in virtual proxy creates user with that different domain(duplicate). We tried different approaches but unfortunately they aren't working.Also went through multiple articles on the internet where they suggest adding attribute in ADFS like "sam-account-name" and "token-groups - unqualified names" but unfortunately we can't add/edit anything at the ADFS side.(https://community.qlik.com/t5/Official-Support-Articles/Qlik-Sense-Set-up-dynamic-domain-name-for-AD...) and (https://community.qlik.com/t5/Deployment-Management/Syncing-Active-Directory-groups-while-using-ADFS...)

Please suggest on how to add users having multiple domains successfully logged in via SAML.Any help will be appreciated. Thanks in advance.