The issue is probably due to the users being part of a large number of Active Directory groups. The solution can be found here. The user cannot authenticate because the Kerberos token that is generated during authentication attempts has a fixed maximum size. Transports such as remote procedure call (RPC) and HTTP rely on the MaxTokenSize value when they allocate buffers for authentication. In Windows Server 2008, the MaxTokenSize value is 12,000 bytes. In Windows 2012 and later version, it's 48,000. Make the recommended registry changes found in the above Microsoft article to resolve this issue and increase the token size.
Possible alternate solution:
The fix was to modify the MaxFieldLength and MaxRequestBytes keys in the System Registry. The following Maximum decimal values must be set in Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\HTTP\Parameters
If the issue is global (all users affected):
Are all prerequisites installed on the server (.NET Framework 4.0 for Qlikview 11+) and if IIS is in use, have all pertinent role features been added? See How to configure: QlikView and IIS for details regarding IIS installation.
Ensure the Service Account running the Directory Service connector has the proper permissions to resolve usernames. This may be an authentication related issue. One way to check this is to view the Windows Logs (Event/Security) to see if the Service Account is failing audit or generating other authentication/permission-related messages.
If the Service Account does not have access to Active Directory, ensure a proper login account is configured in the Directory Service Connector settings in the Management Console.
If the Directory Service Connector is installed on a different server, ensure TCP port 4730 is not blocked inbound or outbound.
Check location of domain controller(s) in relation to servers, if not local to the servers, even with low latent network connections, this may still pose issues when the environment is fairly busy with users coming into the AccessPoint.
Enhanced Security settings for IE should be turned off for Administrators.
Does the QlikView Server have full control on the ProgramData\QlikTech folder? c:\programdata\qliktech\qlikview server as well as the mounts configured for the QlikView Server resource in the Management console should allow Full Control rights.
Are there a large number of folder mounts, or do the folder mounts contain a high number of none-QlikView related files? Note: the QVS scans the folder mount content regularly, which may lead to delays or timeouts.
Ensure the Qlikview Webserver machine connection is using the QlikView Server host name and not Localhost, in QlikView Management Console check the following: System > Setup > QlikviewWebserver > Accesspoint > Server > Connections
Add the QlikView AccessPoint site to the Local Intranet security zone or trusted sites in IE.
Have cookies been allowed in the browser for the currently logged on user?
The account running the Application Pool is the same account as the one running the QlikView Services, or is in the QlikView Administrators and Local Administrators Security Groups. Note: Ensure that the /QvAjaxZfc and /WebTicketSite websites are using the "QlikView IIS" Application Pool and not the DefaultAppPool.