Troubleshooting Content Gateway "Impersonation Failed!" errors

When accessing a network share Admin Repository via the Content Gateway (CGW)* deployed on a Windows server, the CGW endpoint will perform impersonation of the requesting user account. Impersonation is a Windows .NET method that allows the CGW service account to assume the identity of the requesting user. This ensures that any requests made by that user on behalf of the CGW will still be subject to the permissions granted to that specific user.  

When using the Content Gateway on Windows in either a Relay-Endpoint or Endpoint only configuration, the impersonation of the user account will occur on the Endpoint server only. Impersonation of a user may fail for a number of reasons including:

  • The provided user credentials are not valid
  • The user does not have permission to be impersonated
  • The CGW service account does not have permission to impersonate users

In order to troubleshoot "Impersonation Failed" errors, we can take the following steps:

  • On the Endpoint CGW server, increase the CGW logging level to “debug” in the file at: C:\Airwatch\Airwatch.EnterpriseIntegration.Content\web.config (Search file for “level=”). No restart of a service is required for the change to take effect.
  • Replicate behavior, i.e. attempt to log into repository from Content Locker on device, or perform a test connection or sync for the admin repository from the AirWatch Admin Console.

  • In the CGContent.log file, confirm that the “Impersonation Failed” error is occurring for the correct network share path, and the correct username.
  • In the Event Viewer on the Endpoint server open the logs under: Windows Logs>Security, and search for an event with keyword “Audit Failure” and a task category of “Logon failed” or “Credential Validation.”

After confirming the error in the CGContent.log file and collecting the corresponding failed Logon attempt from Event Viewer logs, we can view the event for details on why impersonation failed. Find attached two screenshots from the Event Viewer showing an example of a failed attempt due to a bad password and of a failed attempt due to inadequate permissions. Within each log we can see:

  • “Subject: Security ID”: the Service Account used by CGW
  • “Account Name” and “Account Domain”: the user account for which Logon failed
  • “Failure Reason”: a brief explanation/status of failure
  • “Status”: A hex based version of the Failure Reason
  • “Sub Status”: A failure reason sub status code providing more information on failure 

If the Logon failure gives a reason of: “Unknown user name or bad password” we can view the substatus code to determine which value, username or password, is bad. A substatus code of 0xc000006a indicates a bad password. Other Microsoft error codes can be found online or looked up using Microsoft’s Err.exe utility, available for download here


If the Logon failure gives a failure reason of: “The user has not been granted the requested logon type at this machine”, you must grant some additional permissions to the user account.  


In more locked down environments we may need to grant some or all of these permissions on the Endpoint CGW server under “Local Security Policy>Security Settings>Local Policies>User Rights Assignment:


  • For CGW service account to impersonate other users:
    • “Impersonate a client after authentication”
  • For a user account to be impersonated by the CGW
    • “Allow log on locally”
    • “Log on as a service”
    • “Access this computer from the network”
    • The corresponding “Deny…” policies for these 3 permissions above are not enabled for the user account. 

Be default the Content Gateway service will run as the “Network Service” account. You can view or change the service account used by CGW by opening the IIS Manager and selecting the Advanced Settings option for the ContentGateway application pool.

*Note: In versions less than AirWatch 8.3, the Content Gateway was a component of the Mobile Access Gateway (MAG). All of the above troubleshooting steps are still valid if using previous versions of AirWatch. If troubleshooting on these previous versions please note the following differences: 

  • CGContent.log file mentioned above will instead be replaced with a file called MAG Content.log found at the default path of C:\AirWatch\Logs\MobileAccessGateway\
  • The Application Pool name in IIS is named: "MAGContent"
Have more questions? Submit a request


Article is closed for comments.