Thanks for the detailed reply Andre. On Thu, Jul 09, 2009 at 01:16:06AM -0700, André Warnier wrote: > Ray Van Dolson wrote: > > On Wed, Jul 08, 2009 at 03:35:58PM -0700, André Warnier wrote: > >> Ray Van Dolson wrote: > >>> Hi all; > >>> > >>> I'm trying to strip out NTLM as an authentication option from response > >>> packets (my Apache is acting as a reverse proxy). > >> By curiosity, what does this achieve ? > >> If the origin server requires NTLM authentication for a resource, it is > >> unlikely to be happy with a Basic authentication coming back from the > >> browser. > > > > The server allows both NTLM and Basic (multiple WWW-Authenticate > > headers are transmitted). The client insists on using NTLM if it's > > available which doesn't work properly in a reverse proxy setup (at > > least as far as I understand it). > > > > If I remove the NTLM header, the client falls back to Basic and all > > works correctly. > > > > The client is BIS (Blackberry) so unfortunately I can't change its > > behavior. :) > > > > Allright, that makes sense, and does not sound like you are trying to > pull off a "man-in-the-middle" attack. (And incidentally, you're > right also, it is not really possible to do NTLM auth through a > proxy, for multiple reasons). As I understand it, it's the different source ports that result from having multiple connections to the backend server. I noted that I can typically get things to work if I start up Apache and limit it to only one thread. Sounds like MS took some liberties with their implementation of NTLM as keeping the src port number the same isn't required by RFC? However, it also sounds like MS's own ISA server has problems proxying NTLM, though I haven't tried. > > But first, maybe you should re-think about the whole scheme. If the > server sends back a 401 + WWW-Authenticate, it means that the > requested resource is marked as protected. You will not really be > bypassing this protection, but... The NTLM scheme is > (half-intentionally) limited in scope to a local Windows Domain. > > Basic authentication is not, and by allowing it, you will be in fact > allowing these clients to send user-id and password, almost in clear, > over any untrusted connection, from anywhere. If these user-id and > password are the same as the internal Windows Domain login of these > same users, then I am quite sure someone is going to /strongly/ > object. > > Thus if the Blackberry supports this, I would at least strongly > recommend that you use HTTPS between the client and the proxy (even if > the proxy then forwards to the server in vanilla HTTP). Yes, we absolutely do require HTTPS connections. Obviously someone could still potentially do something nefarious upstream and the credentials would be in a completely insecure state with Basic authentication instead of NTLM.... > > Even in that cases, though, you would have to take care of these > pesky response WWW-authenticate NTLM headers from the server. > > The second line of thought would thus be to investigate if, at the > level of the content server, it would not be possible to arrange that > the Blacberry-accessible content, would be defined so as /not/ to > require authentication. If so, problem solved. > > If not however, then you still have to take care of the back-end > response's WWW-authenticate NTLM headers. I've ended up doing something similar. I've limited my header munging to only the subdirectory that is used by Blackberry's BIS service for authentication. So far this seems to be working fine, and I feel a bit better about throwing this on the production server. > > I had a quick browse through the standard Apache modules, and it > seems that there is nothing that allows to test a /response/ header, > and then do something about the response headers in general. If I > was faced with the same issue, I would immediately think of doing > this via a mod_perl output filter. That is because I have mod_perl > configured on all my servers, and because I like perl and mod_perl, > and because it is the ideal Swiss Army knife for this kind of > situation. Interesting idea. That would definitely be much faster than using an external script output filter. Also note that via correspondance with the author of the patch I mentioned in my original post, he poined me to the one they currently use[1]. I don't think I'm interested in patching my Apache for this, but may file an RFE with my OS vendor (Red Hat). Might be an easier way to get this added to mainline Apache than going through Apache's bugzilla. :-) Though there may end up being a better approach to solving my problem, it does seem like being able to use SetEnvIf on response headers would be something quite useful.... > > But then, do you really need to do something ? > > Say you always delete the WWW-authenticate: NTLM header, (and maybe > always add a WWW-Authenticate: Basic header, although it seems that > this is not necessary, since the server already sends one). I will note that when I use the Header command to delete a header, it deletes all occurrences of it (as far as I understand it). This is why I can't delete _only_ the WWW-Authenticate: NTLM and preserve the Basic one. I have to delete WWW-Authenticates (deletes all) then re-set the Basic. > These headers should only be taken into account by the "browser", > when coming in a 401 response, and be ignored when coming in 200 OK > responses. So what is the problem ? Good point. Thanks again, Ray [1] http://marc.info/?l=apache-httpd-dev&m=114906377610052&w=2 --------------------------------------------------------------------- The official User-To-User support forum of the Apache HTTP Server Project. See <URL:http://httpd.apache.org/userslist.html> for more info. To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx " from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|