From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040323
Description of problem:
mod_ntlm2-0.1.tgz from http://modntlm.sourceforge.net/ compiles and
loads cleanly. Though, it does not work correctly.
The type-1 message parsing, the first step in a NTLM authentication
does not work properly. NT Hostname and NT Domain that the client
presents are not decrypted by the module. You can see that in both the
apache logfiles and the pcap dumps (with ethereal for example). I have
recorded both Apache logfiles and packet capture files of these
unsuccessful requests to authenticated URLs and can provide them on
request. For a comparison I have also recorded successful logins in
apache logfiles and packet captures.
Since mod_ntlm2-0.1.tgz works out-of-the-box with a vanilla
apache-2.0.49, we suppose the bug to be in the Red Hat provided
software, probably in Apache itself.
Instead of being able to access the protected documents the client
loops rerequesting the URL until infinity.
Version-Release number of selected component (if applicable):
httpd-2.0.46-32.ent
How reproducible:
Always
Steps to Reproduce:
1. compile mod_ntlm.so from the archive, load it into apache
2. configure ntlm auth for the document root or another dir
3. try to access the protected directory with an ntlm capable client
4. see the errors in the httpd logfile and in the tcpdump capture
Actual Results: Either when using cURL with NTLM authentication or
any NTLM capable browser (Mozilla, Firefox, Microsoft Internet
Explorer, ...) the request to the protected directory either loops or
is canceled by the client after x unsuccessful retries (x depends on
the client and configuration). It's not possible to use mod_ntlm.so
as-is. We had done this on a not-updated RHEL 3, retried on a fully
up2date RHEL 3, but had the same results!
Expected Results: When using the same mod_ntlm.so source on another
machine with another linux distribution and a vanilla Apache of
version 2.0.49 for example, it works as expected out of the box and
the accesss to the protected directory is only possible when the right
username, password and NT domain credentials are supplied.
Additional info:
I suspect the bug to appear first in the parsing of the client
response to the server's first answer that contains the NTLM auth
token. The communication with the NT PDC seems to work, though.