[jcifs] HTTP POST and Protecting Sub-Content

[Eric]

Michael B Allen wrote:
> I'm working on the NTLM HTTP Authentication Filter documentation. One
> section reads:
> 
> "Once IE has negotiated NTLM HTTP authentication it will proactively
> renegotiate NTLM for POST requests for all content associated with the
> server (based on IP?). Therefore when using HTTP POST requests it is not
> possible to restrict access to some content on the server as IE will
> attempt and fail to negotiate NTLM (it hangs?). This is a protocol
> limitation and there is no clean way to convince IE to stop negotiating
> NTLM (although it may be possible by sending an HTTP error reponse)."
> 
> Would anyone happen to know the details regarding what IE is tracking that
> triggers it to preemptively negotiate NTLM for HTTP POST requests? Is it
> the IP or server name or ...? Also, what is the behavior of a client that
> attempts and fails due to this problem? Finally, was a definitive answer
> to getting IE to stop negotiating POST requests ever established?
> 
> Thanks,
> Mike
> 

Not exactly sure what it tracks.  I know it's not just the open 
connection, because doing a connection close doesn't stop it from 
occuring (at the next POST it the client will send a Type 1 message).  I 
haven't done enough experimentation to determine exactly what it matches 
on (i.e., IP vs. server name vs. FQDN, or if port number matters, etc.).

The client doesn't really fail per se; it basically makes a POST request 
with the Type 1 in the Authorization header and empty content.  So if 
the server deems the empty request as acceptable and sends a 200, the 
client just goes on its way.  I'm not sure what you get if something 
strange is sent back, but it would likely just be the standard IE error 
page.

As far as negating the behavior, I've had success sending a 401 or 403 
back with the final page; i.e.:

1) server asks for auth w/401
2) client sends type 1
3) server sends type 2 w/401
4) client sends type 3
5) server sends back the page content, but a 40x status.

That way, the client thinks that authentication never actually 
succeeded.  I don't know of any way to cancel it once a success status 
is received in response to the Type 3 message; at that point the client 
knows it can successfully perform NTLM with the server, so it sends 
preemptively from then on.


Eric