Hans Leidekker hans@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 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.