Can I indicate to clients that SPNEGO is supported but NTLM is not for HTTP requests?

7
votes

The two WWW-Authenticate additions Microsoft makes use of that I am currently aware of are

  • NTLM
  • Negotiate

If Negotiate is sent down from the server, based on a set of conditions Kerberos will be used

  • Intranet Zone
  • Accessing the server using a Hostname rather then IP
  • Integrated Windows Authentication in IE is enabled, the host is trusted in Firefox
  • The Server is not local to the browser
  • The client's Kerberos system is authenticated to a domain controller

Then Kerberos will be attempted between the server and the client, if something above is not met, then NTLM will be attempted.

My question is, is there some way for the server to indicate that NTLM should not be sent? I currently handle this by keeping track of the request in the session, and if a NTLM message is received, it disables Kerberos and WWW-Authenticate for the rest of that sessions life.

3
kerberosntlmspnegonegotiatewww-authenticate
Are you disabling NTLM because of delegation issues? – Christopher G. Lewis
No, it's simply something I don't currently support in the Tomcat JAAS plugin I've made. It only supports Kerberos/SPNEGO. – Scott Markwell

3 Answers

3
votes

Yes you can. Take a look at the reference docs of the SPNEGO HTTP Servlet Filter project.

2
votes

You can do that, (at least in theory) yes. IE might do totally weird stuff like sending Kerberos Tokens without the appropriate SPNEGO ASN.1 encapsulation, but well, thats a different topic. In a conforming SPNEGO (http://tools.ietf.org/html/rfc4178#section-4.1) Implementation you could do that.

If you can manipulate the NegTokenInit mechTypes member to only contain Kerberos it forces the client to send Kerberos or fail to authenticate.

2
votes

The initial WWW-Authenticate header only specifies negotiate. It can't say anything more, such as "no NTLM".

I think it's possible to respond to the first Authenticate: {Base64 NTLMSSP} header sent by the client with 401 unauthorized and a second Negotiate header, which can include a response token, possibly including a SupportedMechanisms that specifies Kerberos Only.

But I suspect that will only get you "unauthorized", because it was falling back to NTLM in the first place.