Bug 126271

Summary:	httpd does not interoperate with mod_ntlm.so
Product:	Red Hat Enterprise Linux 3	Reporter:	Nicolai Schleifer <nicolai.schleifer>
Component:	httpd	Assignee:	Joe Orton <jorton>
Status:	CLOSED NOTABUG	QA Contact:
Severity:	high	Docs Contact:
Priority:	medium
Version:	3.0	CC:	kluth, pavan.b1985
Target Milestone:	---
Target Release:	---
Hardware:	i686
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2004-06-18 16:04:52 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Nicolai Schleifer 2004-06-18 09:19:02 UTC

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.

Comment 1 Joe Orton 2004-06-18 09:20:44 UTC

Have you enabled KeepAlive support in httpd.conf?  It probably needs
to be enabled to support NTLM.

Comment 2 Nicolai Schleifer 2004-06-18 13:17:46 UTC

Thanks for your help. As you suggested, the KeepAlive setting was set
to "off". I changed it to "on" (server-wide) and tried again.

Unfortunately it does not yet work as expected. The logfile looks
different (less lines per failing request now). Please have a look at
the following snippets from the Apache logfile, that happen when we
place a request that Apache tries to authenticate with NTLM.

==> /var/log/httpd/error.log <==
[Fri Jun 18 15:14:23 2004] [error] [client 193.23.233.249] creating
new ntlm_connection 136712096 31078
[Fri Jun 18 15:14:23 2004] [notice] [client 193.23.233.249] got
auth_line "TlRMTVNTUAABAAAAB7IIoAQABAAoAAAACAAIACAAAABERVYtNDI4N1NUREU="
[Fri Jun 18 15:14:23 2004] [notice] [client 193.23.233.249] got header
with host "DEV-4287", domain "STDE"
[Fri Jun 18 15:14:23 2004] [error] [client 193.23.233.249] received
msg1 136712096 31078

==> /var/log/httpd/stab-tux-intra/access.log <==
193.23.233.249 - - [18/Jun/2004:15:14:23 +0200] "GET / HTTP/1.1" 401
495 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)" "-"

==> /var/log/httpd/error.log <==
[Fri Jun 18 15:15:03 2004] [error] [client 193.23.233.249]
send_ntlm_challenge: no conn. handle...trouble communicating with
PDC/BDC? returning internal server error

==> /var/log/httpd/stab-tux-intra/access.log <==
193.23.233.249 - - [18/Jun/2004:15:14:23 +0200] "GET / HTTP/1.1" 500
639 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)" "-"

Comment 3 Nicolai Schleifer 2004-06-18 13:20:10 UTC

Sorry. The PDC seems down, suddenly.. Weird. I have to recheck, when
it is back on.

Comment 4 Nicolai Schleifer 2004-06-18 15:27:34 UTC

Problem solved. Thanks a lot!

Comment 5 Joe Orton 2004-06-18 16:04:52 UTC

Thanks for letting us know.  Possibly KeepAlive will be on by default
for RHEL4 which would avoid this issue; it's still under consideration.

Comment 6 Pavan Banda 2011-06-22 23:42:10 UTC

Hi Team,
We are not using a direct DC instead we are using a VIP URL

    AuthType NTLM
     NTLMAuth on
     NTLMAuthoritative on
     NTLMDomain /* Here Domain name (we use ads) */
     NTLMServer /*Here goes VIP URL */
    
and as per the above give suggestion KeepAlive is ON. But still we are observing the below Error :
[Wed Jun 22 09:27:53 2011] [error] 25176 - RFCNB_Call: RFCNB_Session_Req failed with errno -1 - Called_Name ADS Calling_Name webservername
[Wed Jun 22 09:27:53 2011] [error] 25176 - RFCNB_Call: RFCNB_Session_Req failed with errno -1 - Called_Name ADS Calling_Name webservername
[Wed Jun 22 09:27:53 2011] [error] [client ] 167565392 25176 ********************* - send_ntlm_challenge: no conn. handle...trouble communicating with PDC/BDC? returning internal server error

please help me out on this error...Thanks