When opening AccessPoint, users are not seeing the correct documents even though they are part of the correct groups

[Sonja_Bauernfeind]

When opening AccessPoint, users are not seeing the correct documents even though they are part of the correct groups.

• The QlikView Server is set to use DMS Security.
• There is a directory connector (Custom, Active Directory. Configurable ODBC or Configurable LDAP) and it works ok, because when you search for a user on the "Users" tab in the QMC, the correct groups show up.
• In the document settings, on the authorization tab for the document, a group which the user is a member of has been named.
• Yet, in AccessPoint, when logged in as this user, the document does not show up.

This article outlines how to start troubleshooting this scenario.
 

Resolution:

After attempting to open AccessPoint, open the web server log (under C:\ProgramData\QlikTech\WebServer\Log).

This should have an entry for when the Web Server contacts the QVS and issues a "GetAdminDocListForUser" request:

015-02-05 14:01:15.5244203    Information    <Global method="GetAdminDocListForUser"><UserId>domain\user1</UserId><Type>1</Type><ExtendedDocInfo>1</ExtendedDocInfo><GroupList><string>group1</string></GroupList><GroupListIsNames>true</GroupListIsNames></Global>

The above line shows that user "domain\user1" is a member of "group1". The QVS then uses that information to respond with the appropriate list of documents that the user should be able to see.

The group in the "GetAdminDocListForUser" request can come from:

• The webticket request?
• Browser authentication
• The DSC

Scenario 1: There is no group supplied in the GetAdminDocListForUser request

This can happen if the AccessPoint web application, hosted on QVWS or IIS, has attempted to contact the Directory Service Connector (DSC) but has not received any group information for the user.

Possible reasons for this:

• Is the correct URL configured for the DSC and QDS?

If using multiple servers, using "localhost" to identify the server running specific services (i.e. QDS or DSC) will not work, as the location of the service is still not known.

• Is the AccessPoint web application set up to communicate with the correct DSC?

This can be checked in the QMC, on the "General" of the Web Server, where the correct "Directory Service Connector" can be selected from a drop-down list:

Or it can be checked directly in the C:\ProgramData\QlikTech\WebServer\config.xml where this setting is stored.

• Did communication fail?

Using fiddler while logged in as the same user as running the QlikView Services or IIS application pool may, in that case, show a failure when the web process atttempts to communicate with the DSC on port 4730:

 
This communication could fail for example if Siteminder is being used and intercepts the traffic. 

Or if the Application pool account in IIS which runs the AccessPoint does not run as the same user as the other QlikView Services.

• The user is in the form "Domain\UserID". Double-check that there a Directory Service provider for this domain?

Scenario 2: The wrong group is supplied in the GetAdminDocListForUser request

• If using webtickets for authentication and if a list of groups was supplied with the webticket request, then that is where the groups are taken from, and the DSC does not get contacted.

So if the group information is wrong, double check that the webticket request contains the correct groups, or none at all.

If no groups are supplied in the webticket request then the AccessPoint web application will instead contact the DSC to get the groups.

• If using NTLM for authentication, the group membership information is taken from the Windows authentication.

Since Windows has already told Accesspoint the username and also about the group membership for the user, the Directory Service Connector will not be asked to resolve groups. So Accesspoint will show the documents based on the group membership from Windows Authentication, not the group membership in the Directory Service Connector.
If this is not the desired outcome, then NTLM is not a suitable authentication mechanism, and it woudl make sense to switch to another authentication method that either identifies the groups correctly or not at all.

Scenario 3: The correct group is supplied in the GetAdminDocListForUser request

If this is the case, then check in the web server log on the line after the "GetAdminDocListForUser" request. This should contain a <DocList> response which should contain the correct documents. If that list does not contain the expected document then check on the QVS side.

For example, in the QMC, looking at the authorization for the document - is the correct group really assigned as a "Users Authorized to Access Document"?
 

NOTE: There is a performance improvement in the DSC processes to LDAPs which will be included in the 12.20 track and later related to group lookups.