Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use GSS_C_NT_HOSTBASED_SERVICE, not GSS_KRB5_NT_PRINCIPAL_NAME #474

Open
nicowilliams opened this issue May 8, 2020 · 5 comments
Open

Comments

@nicowilliams
Copy link

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/someserver.ad.foo.example@AD.FOO.EXAMPLE, but mssql-cli constructed a raw Kerberos principal name of the form MSSQLSvc/someserver.ad.foo.example@<default_realm>, i.e., MSSQLSvc/someserver.ad.foo.example@N.FOO.EXAMPLE. The client credentials we for user@AD.FOO.EXAMPLE...

What happened then was that the client fetched a cross-realm TGT, krbtgt/N.FOO.EXAMPLE@FOO.EXAMPLE then asked a KDC for N.FOO.EXAMPLE for a service ticket for MSSQLSvc/someserver.ad.foo.example@N.FOO.EXAMPLE, 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/someserver.ad.foo.example@AD.FOO.EXAMPLE.

If mssql-cli had either use GSS_C_NT_HOSTBASED_SERVICE and MSSQLSvc@someserver.ad.foo.example, 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.

@nicowilliams
Copy link
Author

See FreeTDS/freetds#338.

@nicowilliams
Copy link
Author

MIT Kerberos and Heimdal nowadays support :<port> in service principal names, too. FYI.

@nicowilliams
Copy link
Author

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.

@nicowilliams
Copy link
Author

@detule
Copy link
Contributor

detule commented Jun 4, 2020

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants