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
Comments
See FreeTDS/freetds#338. |
MIT Kerberos and Heimdal nowadays support |
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. |
I looked into this once (how does their service construct principal names). I believe it's somewhere in here: Good luck. |
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
, andN.FOO.EXAMPLE
, where on a Linux system[libdefaults] default_realm = N.FOO.EXAMPLE
, and the SQL Server's principal really isMSSQLSvc/someserver.ad.foo.example@AD.FOO.EXAMPLE
, butmssql-cli
constructed a raw Kerberos principal name of the formMSSQLSvc/someserver.ad.foo.example@<default_realm>
, i.e.,MSSQLSvc/someserver.ad.foo.example@N.FOO.EXAMPLE
. The client credentials we foruser@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 forN.FOO.EXAMPLE
for a service ticket forMSSQLSvc/someserver.ad.foo.example@N.FOO.EXAMPLE
, which yielded a referral toFOO.EXAMPLE
, which then rejected the request because it would mean doubling back toAD.FOO.EXAMPLE
, which would be a loop.Constructing an alternate
krb5.conf
with[libdefaults] default_realm = AD.FOO.EXAMPLE
and using it by setting theKRB5_CONFIG
environment variable worked around the problem by causingmssql-cli
to construct the correct service principal name,MSSQLSvc/someserver.ad.foo.example@AD.FOO.EXAMPLE
.If
mssql-cli
had either useGSS_C_NT_HOSTBASED_SERVICE
andMSSQLSvc@someserver.ad.foo.example
, orGSS_KRB5_NT_PRINCIPAL_NAME
andMSSQLSvc/someserver.ad.foo.example@
(note the "empty" realm), then it would have worked without us having to work around it.The text was updated successfully, but these errors were encountered: