The two WWW-Authenticate additions Microsoft makes use of that I am currently aware of are <ul> <li>NTLM</li> <li>Negotiate</li> </ul> If Negotiate is sent down from the server, based on a set of conditions Kerberos will be used <ul> <li>Intranet Zone</li> <li>Accessing the server using a Hostname rather then IP</li> <li>Integrated Windows Authentication in IE is enabled, the host is trusted in Firefox</li> <li>The Server is not local to the browser</li> <li>The client's Kerberos system is authenticated to a domain controller</li> </ul> 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.

The initial <code>WWW-Authenticate</code> header only specifies <code>negotiate</code>. 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 <code>401 unauthorized</code> and a second <code>Negotiate</code> header, which can include a response token, possibly including a <code>SupportedMechanisms</code> that specifies Kerberos Only. But I suspect that will only get you <code>"unauthorized"</code>, because it was falling back to NTLM in the first place.

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

Tags:

kerberos

ntlm

negotiate

www-authenticate

spnego

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.

574

asked Jan 28 '09 23:01

Scott Markwell

3 Answers

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.

168

answered Sep 30 '22 03:09

davenpcj

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

answered Sep 30 '22 04:09

Pat Gonzalez

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 (https://www.rfc-editor.org/rfc/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.