Who is this article for?

Users encountering the error when accessing the system.

No special access or permissions are required.

This article explains why the error occurs and how to resolve it.

1. Issue

When accessing the application, the user will encounter the "The caller was not authenticated by the service" error.

This authentication error typically stems from one of the following issues:

• User's PC not being a member of a Windows domain trusted by the application server
• Application server's domain membership has broken
• Server configuration issues (DisableLoopbackCheck)
• Windows updates causing Kerberos PAC validation conflicts
• Particularly common on Windows Server 2012 R2 after updates

Important
Windows Server 2012 R2 and earlier are no longer supported by Microsoft. If you are running unsupported operating systems then we cannot support you. You should upgrade to a supported Windows Server version and continue troubleshooting only if the error persists after upgrade.

2. Troubleshooting

The error can appear in multiple locations within your system:

• Desktop application - The error displays on the user's screen at application startup.
• Service logs - Check the following logs:
  • Robot service log
  • WebUI log
  • WebService log

3. Verifying error messages

To confirm the authentication issue:

• Check for the primary exception message: "EXCEPTION: SecurityNegotiationException with message: The caller was not authenticated by the service and source: mscorlib".
• Check for the inner exception: "The request for security token could not be satisfied because authentication failed."
• Check for the alternative error format: "Cannot Initialize AgentHelper: The caller was not authenticated by the service."

4. Checking events

To identify system-level authentication issues:

1. Open Event Viewer.
2. Navigate to System log.
3. Check for the error: "The program w3wp.exe, with the assigned process ID xxxx, could not authenticate locally by using the target name host/[server.domain.com]. The target name used is not valid. A target name should refer to one of the local computer names, for example, the DNS host name."
4. Check for Kerberos-related errors: "During Kerberos Network Ticket Logon, the service ticket for [service account] from Domain [domain] could not be forwarded to a Domain Controller."
5. Check for PAC validation errors: "The digitally signed Privilege Attribute Certificate (PAC) that contains the authorization information for client <Hostname>$ in realm <Domain> could not be validated."

5. Solution (Users)

5.1. Individual user

To resolve the error if it affects a single user:

1. Ensure the client PC is in a domain trusted by the application server's domain.
2. Clear cached credentials in Windows Credential Manager after domain changes.

5.2. All users

To resolve the error if it affects all users, work through these troubleshooting steps.

5.2.1. Verify server operating system

Check if the application server is running Windows Server 2012 R2 or earlier. These are no longer supported by Microsoft. If you are running unsupported operating systems then we cannot support you. You should upgrade to a supported Windows Server version.

5.2.2. Check Windows updates

To address Kerberos PAC validation issues introduced by Microsoft security updates, ensure all systems are fully updated:

1. Update the client PC.
2. Update the application server.
3. Update the domain controller.

5.2.3. Verify domain membership

To confirm the application server is properly configured:

1. Confirm the server is properly joined to the domain.
2. Re-join the server to the domain if uncertain about its membership status.

5.2.4. Check DNS and Kerberos configuration

To resolve network-level authentication issues:

1. Verify DNS resolution is working correctly.
2. Check for Kerberos configuration issues.
3. Consult your network administrator if needed.

7. Solution (Service logs)

If the error appears in Robot, WebUI, or WebService logs, this solution adds the server's FQDN to the Local Security Authority registry settings. This is the recommended approach by Microsoft.

Alternatively, you can disable the authentication loopback check entirely. This is less targeted than adding BackConnectionHostNames but may be simpler in some environments.

Refer to Microsoft documentation for the DisableLoopbackCheck registry setting.

Important
Always back up the registry before making changes.

To resolve the issue:

1. Open the Registry Editor.
2. Navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0/.
3. Edit the Registry Value:
   • Type - Multi-string value
   • Name - BackConnectionHostNames
   • Data - server.domain.com (your server's FQDN)

7.1. PowerShell

To implement the registry change using PowerShell (replace server.domain.com with your server's FQDN):

1. Open PowerShell as Administrator.
2. Run the command:

Set-ItemProperty -Path HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0 -Type MultiString -Name "BackConnectionHostNames" -Value "server.domain.com"

7.2. REG file

To implement the registry change using a REG file:

1. Create a new text file.
2. Add the following content: Windows Registry Editor Version 5.00 followed by [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0] and "BackConnectionHostNames"="server.domain.com".
   Replace server.domain.com with your server's FQDN.
3. Save the file with a .reg extension.
4. Double-click the file to import it into the registry.

7.3. Registry editor

To implement the registry change manually:

1. Open regedit.exe.
2. Navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0.
3. Right-click the right pane.
4. Click New.
5. Select Multi-String Value.
6. Name it BackConnectionHostNames.
7. Double-click the new value.
8. Enter your server's FQDN.

Note
A server restart may be required after making registry changes.