[PATCH 8/9] kerberos: Don't include GSS_C_DCE_STYLE in default gss_init_sec_context() flags.

[Hans Leidekker]

On Tue, 2018-01-30 at 17:47 +0800, Dmitry Timoshkov wrote:
> Hans Leidekker <hans at codeweavers.com> wrote:
> 
> > On Thu, 2018-01-25 at 20:51 +0800, Dmitry Timoshkov wrote:
> > > Sure, I can take a look. Can you show me how to reproduce your failure?
> > > 
> > > Just run the tester, type http://wintest2.test.local in the "Url:" field
> > > and press "Test" button. Make sure that you have a valid TGT in the cache.
> > > (I assume that SPN "HTTP/wintest2.test.local" from the log you've provided
> > > ealier exists on the server, otherwise you may need to list available SPNs
> > > on the Windows side using 'setspn -T yourdomain.com - Q */*' and find one
> > > starting with HTTP/ prefix).
> > 
> > The tool expects a web server with a specific configuration. I
> > installed IIS 7.0, added the 'Windows Authentication' feature and
> > enabled it for the test site.
> > 
> > It turns out that it's testing the Negotiate provider, which doesn't do
> > the same three-leg authentication as the Kerberos provider.
> 
> Thanks for the ongoing efforts.
> 
> The Negotiate provider is just a thin layer that switches between NTLM
> and Kerberos, probabaly IIS doesn't use Kerberos for some reason and
> falls back to NTLM. Inspecting HTTP headers in Kerberos Tester or HTTP

It detects the authentication type as Kerberos.

> exchange in Wireshark may help. I have created a simple test app that
> replicates in plain C what Kerberos Tester is doing and does some
> additional logging/HTTP headers dumping.
> 
> On the other hand since I have a working server with proper Kerberos
> support and dedicated SPNs I could try to take care of the problem
> on my own, and you then may switch to reviewing secur32 patches in
> the queue. Just let me know if you prefer going this way.

Sure, we can revisit this when we have a better understanding of the
problem.