runtime: WCF on Linux - Kerberos Authentication with UpnEndpointIdentity seems to be sending the wrong name-type to the KDC.

Hi,

So I’m really struggling with getting a .NET Core app running on Linux because of Kerberos. The app is a client that is communicating with a WCF service running on a windows server. The Service runs under a service account, so the client specifies a UpnEndpointIdentity. This works great on windows, but when trying to run it on Ubuntu, I’m getting GSSAPI errors. Specifically this:

System.ServiceModel.Security.SecurityNegotiationException: Authentication failed, see inner exception. —> System.Security.Authentication.AuthenticationException: Authentication failed, see inner exception. —> System.ComponentModel.Win32Exception (0x80090020): GSSAPI operation failed with error - Unspecified GSS failure. Minor code may provide more information (Server not found in Kerberos database).

I’m no Kerberos expert, but I’ve started to dig into the Wireshark traces and it looks like on windows it’s sending a request to the KDC with an sname name-type of kRB5-NT-SRV-HST (3). On Ubuntu, it’s instead sending name-type: kRB5-NT-PRINCIPAL (1). The KDC is rejecting the request with KRB5KDC_ERR_S_PRINCIPAL_UNKNOWN, which makes sense since the client is asking for a host instead of a principal.

Also, I’m able to correctly acquire a service ticket using kgetcred for the UPN, and I can see it correctly sent in the wireshark trace. Is this a bug in .NET Cores interaction with GSSAPI, or WCF, or am I just missing something? @davidsh Wrote some of this code so I’m hoping he can help.

I’m happy to provide the Wireshark traces if that will help, or any more details needed.

Thanks!

About this issue

  • Original URL
  • State: open
  • Created 5 years ago
  • Comments: 24 (12 by maintainers)

Commits related to this issue

Most upvoted comments

As mentioned in the comment above: https://github.com/dotnet/runtime/issues/31040#issuecomment-537744414

Server not found in Kerberos database means the SPN of the target server used by the client doesn’t match anything on record in AD. Find out what SPN is being used and update the client to use it, or update the AD service account with the SPN that’s actually being used.