FreeTDS Development Group

[Achim Grolms <achim AT grolmsnet.de>]

On Thursday 08 November 2007, you wrote:

> > But why to do so?
> > passing GSS_NT_HOSTBASED_SERVIVE
> > to gss_import_name() makes the GSSAPI do this work
> > internally.
>
> Yes but it do not support spn like MSSQLSvc/fqdnhostname:port@DOMAIN which
> is required by mssql...

I am sorry, I simply do not understand the words.
Today I have done a test using WinXP and Microsoft ODBC driver
log to a connect to a WIndows2005 SQL Server.

The resulting Kerberos5 service-ticket shown by kerbtray.exe
has principalname of format
'cifs/fqdnhostname'. That would result in passing
'cifs@fqdnhostnam' to gss_import_name.

I do not understand why to use 'MSSQLSvc' as a servicename?

> Is that is a bit complicated to write code.... I should send to mssql some
> token that require a reply but I don't know how...

add GSS_C_MUTUAL_FLAG to the flags of gss_init_security_context.

> The idea is to save the state in TDSSOCKET if CONTINUE_NEEDED is returned
> and handle when server reply.

yes, a ContextHandle-object corresponds to the a socket,
and a got idea ist to store both in the same datastructure.


> Well... if I use a wrong password and client login correctly with my login
> it should work.

I do not get the point... In Kerberos5 there is no "password",
there is only a TGT (in credentials cache).
What's the meaning of "password" in this context?

> Also adding that I send a kerberos token and server agree 
> seems ok, I hope mssql do not authenticate with an invalid kerberos
> token...

That's easy to check - simply put an invalid datastruture
into the Tokens' place and see what happens.

Does the Server do some logging that is useful to understand what is 
happening?

Achim