Skip to main content



No record found.

AL Language extension Windows authentication does not work with constrained delegation (Kerberos) since 9.5.x runtime onwards (20.5 Cumulative Update)

This problem was reported by several partners in the following GitHub entries:


To summarize, if you have enabled constrained delegation (Kerberos) and use Windows Authentication to perform your development activities, any AL language extensions higher than 9.5.x (included with 20.5 Cumulative Update and onwards) will prevent any push/pull activity such as downloading symbols or debugging dev extensions.

An example of the error raised when downloading symbols could be similar to the following:

Processing of message 'al/downloadSymbols' failed with error: 'The target principal name is incorrect.'
System.ComponentModel.Win32Exception (0x80090322): The target principal name is incorrect.
at System.Net.NTAuthentication.GetOutgoingBlob(Byte[] incomingBlob, Boolean throwOnError, SecurityStatusPal& statusCode)
at System.Net.NTAuthentication.GetOutgoingBlob(String incomingBlob)
at System.Net.Http.AuthenticationHelper.SendWithNtAuthAsync(HttpRequestMessage request, Uri authUri, Boolean async, ICredentials credentials, Boolean isProxyAuth, HttpConnection connection, HttpConnectionPool connectionPool, CancellationToken cancellationToken)


Changing from Kerberos to negotiate with NTLM, it would work just fine but this will change the authentication type and negotiating will always fall back from constrained delegation to NTLM.



 After several rounds of investigations, it was found that SPN configuration is not a problem. The issue was related to the VSIX EditorServices.Host upgrade from .NET 5 to .NET 6.


The logic that encapsulates sending of request that is failing didn't change between 20.x and 21.x, however what has changed is the target core. Such change has brought some differences around Kerberos and handling of SPNs on the client side which results in a wrong target principal name selection, as per error message.

 More in depth, it looks like moving to .NET 6 this could be the specific root cause breaking change:

Breaking change: Port removed from SPN for Kerberos and Negotiate - .NET | Microsoft Learn

Where it is stated that without port in the SPNs it will not work as expected on non-standard HTTP ports and it is required (mandatory) to add port no. to SPNs.

You might have a flavor of this on this unofficial blog post too Kerberos and non-standard port number - Tomek's DS World (



  1. Run an elevated command prompt or PowerShell ISE in the machine where Visual Studio Code is installed.
  2. Execute the following script:


  1. Restart Visual Studio Code

See more: Networking config settings - .NET | Microsoft Learn



VSIX compilation has been changed to cope with this problem and the issue is resolved with:

  • 21.7 May 2023 Cumulative Update (VSIX-only changes)
  • 22.1 May 2023 Cumulative Update (VSIX-only changes)


*This post is locked for comments