Use GSS_C_NT_HOSTBASED_SERVICE, not GSS_KRB5_NT_PRINCIPAL_NAME
Using GSS_KRB5_NT_PRINCIPAL_NAME, and setting the realm to anything other than the empty realm, is a recipe for failure in multi-realm environments.
For example, today I had to debug a case involving three realms, let's call them AD.FOO.EXAMPLE, FOO.EXAMPLE, and N.FOO.EXAMPLE, where on a Linux system [libdefaults] default_realm = N.FOO.EXAMPLE, and the SQL Server's principal really is MSSQLSvc/[email protected], but mssql-cli constructed a raw Kerberos principal name of the form MSSQLSvc/someserver.ad.foo.example@<default_realm>, i.e., MSSQLSvc/[email protected]. The client credentials we for [email protected]...
What happened then was that the client fetched a cross-realm TGT, krbtgt/[email protected] then asked a KDC for N.FOO.EXAMPLE for a service ticket for MSSQLSvc/[email protected], which yielded a referral to FOO.EXAMPLE, which then rejected the request because it would mean doubling back to AD.FOO.EXAMPLE, which would be a loop.
Constructing an alternate krb5.conf with [libdefaults] default_realm = AD.FOO.EXAMPLE and using it by setting the KRB5_CONFIG environment variable worked around the problem by causing mssql-cli to construct the correct service principal name, MSSQLSvc/[email protected].
If mssql-cli had either use GSS_C_NT_HOSTBASED_SERVICE and [email protected], or GSS_KRB5_NT_PRINCIPAL_NAME and MSSQLSvc/someserver.ad.foo.example@ (note the "empty" realm), then it would have worked without us having to work around it.
See https://github.com/FreeTDS/freetds/issues/338.
MIT Kerberos and Heimdal nowadays support :<port> in service principal names, too. FYI.
Hmm, where in this codebase might a fix go? I couldn't find anything about initiation of GSS security contexts. There are large binary artifacts in the repo, which is where I imagine the code is.
https://krbdev.mit.edu/rt/Ticket/Display.html?id=8903
I looked into this once (how does their service construct principal names).
I believe it's somewhere in here:
https://github.com/dotnet/corefx/blob/release/2.2/src/System.Data.SqlClient/src/System/Data/SqlClient/SNI/SNIProxy.cs#L344
Good luck.