WWW-Authenticate uses NTLM and not Kerberos

Question

I'm running a NodeJS server on a Windows Server 2008.

The server doesn't do much but I set the header for 401, WWW-Authenticate Negotiation which I know can go either with his default Kerberos authentication or if it's not available then with NTLM.

I downloaded fiddler and discovered that when I try to reach the server it tries to authenticate with NTLM(prompt me for username and password) rather than Kerberos, even though the computer is in the same domain as the server and when I do run the command "klist" it does show me that he has tokens which means that he already authenticated with Kerberos(doesn't it?).

My question is how can I make it authenticate with Kerberos rather than NTLM - why does he go to NTLM in the first place?

Any ideas?

Answer 1

As this hasn't been marked as fixed I thought I would add a solution which worked for me. YMMV as in my environment we have multiple forests with trust relationships.

In my case, the user running the browser (and therefore making the HTTP GET) was in DOMA, but the web server was joined to DOMB. When the client tried to find the SPN of HTTP/webserver.domainb.example.com, it was looking for it in the DOMA.

I wrongly assumed that because a bi-directional trust relationship existed between DOMA and DOMB that it would figure out to look in DOMB and do so. Unfortunately it does not and you must Configure Kerberos Forest Search Order. This may be done per client (Computer Configuration → Policies → Administrative Templates → System → Kerberos → Use forest search order) on Windows 7, or per KDC (Computer Configuration → Policies → Administrative Templates → System → KDC → Use forest search order) on Windows Server 2008R2.

Note: Michael-O's advice to use Wireshark and look for TGS-REQ messages was what led me to finding the KFSO setting so many thanks to him.

Answer 2

Most likely, you need to read up on Kerberos. You probably have a TGT (ticket granting ticket) , which proves you authenticated to AD (KDC). You still need a ST (service ticket) for the specific service/server instanced. http/servername. For this to work, you need an SPN registered for the service. the SPN must be registered to the account that will be decrytping the ST.

Fiddler showing that you don't send a ST shows that you didn't get one. You likely will need a sniffer, not just Fiddler. You will see, on port 88, your workstation try to request the ST from a KDC, then fail, then fall back to NTLM. You want to see the ST req get back a ST.

this is a great starter, despite being from 2000 http://technet.microsoft.com/en-us/library/bb742431.aspx

For more meaningful assistance, I'd need to see your app URL, your SPN info via setspn -l , and server hostname.

Answer 3

You client is probably unable to obtain a server ticket for that machine. Use Wireshark and check for Kerberos TGS-REQ messages. Please search SO for my similar answers, I was already able to help in such situations.