Hans Leidekker hans@codeweavers.com wrote:
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.
That's a good starting point. Does KRB5_TRACE=/dev/stdout in addition to WINEDEBUG=+secur32,+kerberos help to shed some light on the reason of the failure? Or you didn't try to run the Kerberos Tester on the Wine side and just tried it under Windows? I've personally found out that usually tracking down kerberos related failures under linux+wine is much easier than under windows.
Just in case I'm attaching a test with source that I'm using for internal kerberos testing, the test replicates what Kerberos Tester is doing, but doesn't require dotnet. The test needs a server address of a kerberized HTTP server. $> KRB5_TRACE=/dev/stdout WINEDEBUG=+secur32,+kerberos wine kerberos.exe myserver.sample.com
The test dumps server responces and it's usually very helpful to look at the ticket generated by InitializeSecurityContext(), if there is "NTLM" signature there, then kerberos is not used for some reason.