Out of box SSO using AD not working. Prerequisites?

[davetrentwipro]

Installed QS Server using a server-local service account with admin rights on an Azure VM that is connected to our domain.

If I try to log on to the Hub or QMC via a client on the domain I'm asked to authenticate with ID and password; a domain ID doesn't work, only a server local account does.  Ditto if I do try to log on to the Hub or QMC on the server.

Via the Operations Monitor, Log Detail view I see the Proxy Service threw the error: Authenticate Request (ReceiveRequestAsync) failed.

My gut is that Qlik isn't able to use the domain AD.  Does the Qlik Sense server account need to be a domain account (with some special AD rights)?  Does there need to be some other service running on the server to use the AD I'm not aware of?

Any suggestions would be appreciated

[awhitfield]

Hi David,

have you checked:

https://help.qlik.com/en-US/sense/April2018/Subsystems/PlanningQlikSenseDeployments/Content/Deployme...

best regards

Andy

[Levi_Turner]

My gut is that Qlik isn't able to use the domain AD.  Does the Qlik Sense server account need to be a domain account (with some special AD rights)?  Does there need to be some other service running on the server to use the AD I'm not aware of?

From the Qlik Support side, we will always recommend using a domain account when the server is on the domain. This makes permissions to remote resources a much easier adventure.

If this is not possible (right now or long-term), then you can do the following:

• QMC > User Directory Connectors
• Create New > Active Directory
• Expand the Connection section on the right hand side
  • The Path likely has already been picked up
  • Enter in a valid set of domain credentials for the User Name and Password fields

This will allow you to leverage domain credentials to have the trust needed to make a query to the domain controller(s).

The only aspect to take note of here is that be sure that these credentials are updated whenever they are updated on AD. For example, if you use your credentials then you likely have a 30/60/90 day password expiration policy where you need to change you password. Once doing this for yourself, the UDC will need updating as well.

Hope that helps.

[davetrentwipro]

Thanks much Levi!

Created a UDC against the AD.  Query ran successfully as per the logs: am waiting for "asynchronous" response from the AD.  (Did uncheck the box "existing users" box.)

I entered the following filter so as not to bring down the whole AD

( &(objectCategory=person)(objectClass=user)(cn=Jay*) )

Quick question: Does the user identified by the UDC need to have User object update rights (e.g. Root Admin) as a QS user in order to allow a write of the retrieved users?  Am curious as I don't see an owner attribute for UDC.

[Levi_Turner · Accepted solution]

I am not 100% sure that filter will be successful. I would expect something like this: (&(objectCategory=person)(objectClass=user)(memberof=CN=Example Group,OU=DL,OU=Groups,DC=company,DC=com))

There's an article in our KB in the Support Portal titled Qlik Sense: How to create a filter in Directory Connector (and test it), which can be used to test LDAP filters outside of Sense since Qlik just sends the query to AD.

Technet documentation on the matter: http://social.technet.microsoft.com/wiki/contents/articles/5392.active-directory-ldap-syntax-filters...

Quick question: Does the user identified by the UDC need to have User object update rights (e.g. Root Admin) as a QS user in order to allow a write of the retrieved users? Am curious as I don't see an owner attribute for UDC.

No, they do not. The account that does the changes is the sa_repository account which has sufficient rights inside of Qlik Sense to do what it needs to do.

[davetrentwipro]

Thanks again Levi (and Andy)!

I used the Support document How To Validate LDAP User Directory Connection to confirm what the QS Server logs were showing me: neither the service account (local to server) or my domain account (no special privileges) had rights to access the company LDAP.  We have a special rights account that didn't throw errors and also worked with the Softerra LDAP Browser.

I used that in conjunction with the article you suggested and associated links to learn a bit more about LDAP filters and had tried (&(objectClass=user)(cn=Jaya*)) with success.  Admitted will need different, more targeted filters going forward -- step 1 was to make it work.

Still need to confirm one of the users fetched can authenticate but am optimistic -- assume it worked unless I repost