2

I have an Apache 2.2 server running Apache2::AuthenNTLM. I have successfully Apache2::AuthenNTLM configured it to the point that it connects to the domain controller. However, valid username / password combinations show "Wrong user/password" in the logs and do not authenticate.

This is the apache configuration:

PerlAuthenHandler Apache2::AuthenNTLM
AuthType ntlm
AuthName "NTLM TEST"
Require valid-user
# DOMAIN has is the domain users authenticate to, DOMAIN\username
# subdomain points to the domain controller. subdomain.domain.local.
# /etc/hosts maps subdomain to the correct IP.
PerlAddVar ntdomain "DOMAIN subdomain"
PerlSetVar ntlmdebug 1
PerlSetVar defaultdomain DOMAIN
PerlSetVar splitdomainprefix 1

This is the output of the apache log:

[4460] AuthenNTLM: Start NTLM Authen handler pid = 4460, connection = -1147051008 conn_http_hdr = Keep-Alive  main =  cuser =  remote_ip = 10.119.1.141 remote_port = 13873 remote_host = <> version = 0.02 smbhandle = 
[4460] AuthenNTLM: Object exists user = \
[4460] AuthenNTLM: Authorization Header NTLM
[4460] AuthenNTLM: protocol=NTLMSSP, type=1, flags1=7(NEGOTIATE_UNICODE,NEGOTIATE_OEM,REQUEST_TARGET), flags2=130(NEGOTIATE_ALWAYS_SIGN,NEGOTIATE_NTLM), domain length=0, domain offset=0, host length=0, host offset=0, host=, domain=
[4460] handler type == 1 
[4460] AuthenNTLM: Connect to pdc = subdomain bdc =  domain = DOMAIN
[4460] AuthenNTLM: timed outwhile waiting for lock (key = 23754)
[4460] AuthenNTLM: leave lock
[4460] AuthenNTLM: verify handle  smbhandle == -1146832856 
[4460] AuthenNTLM: charencoding = 1
[4460] AuthenNTLM: flags2 = 130
[4460] AuthenNTLM: Send header: NTLM ...
[4460] AuthenNTLM: verify handle = 1 smbhandle == -1146832856 
[4460] AuthenNTLM: Start NTLM Authen handler pid = 4460, connection = -1147051008 conn_http_hdr = Keep-Alive  main =  cuser =  remote_ip = 10.119.1.141 remote_port = 13873 remote_host = <> version = 0.02 smbhandle = 
[4460] AuthenNTLM: Object exists user = \
[4460] AuthenNTLM: Authorization Header NTLM
[4460] AuthenNTLM: protocol=NTLMSSP, type=3, user=username, host=host, domain=DOMAIN, msg_len=0
[4460] handler type == 3 
[4460] AuthenNTLM: verify handle = 3 smbhandle == -1146832856 
[4460] AuthenNTLM: Verify user user via smb server
[4460] AuthenNTLM: rc = 3  ntlmhash = *****************

Virtual host log:

[Mon Apr 18 15:36:38 2011] [error] Wrong password/user (rc=3/1/327681): DOMAIN\\username for /ntlm

I don't know how to troubleshoot this, I'm a linux guy and Windows networks are a foreign language to me. I am sure that the domain controller is the one that has my AD entry and I know the username and password should work. Thanks.

EMI
  • 53
  • 2
  • 8
  • Update over a year later: PyAuthenNTLM2 (below) works in the case the linux machine is not joined to the domain, mod_auth_ntlm_winbind is another option if the machine is joined with a working samba/winbind installation. – EMI Jun 25 '12 at 17:07

1 Answers1

4

You do not say which sort of client you use, but once I experienced the same behavior, and it turned out to be related to the new default NTLM client settings in Windows 7.

Older versions of Windows use NTLMv1. Since NTLMv1 can be cracked in minutes, Microsoft has switched to NTLMv2 in Vista. Unfortunately, AuthenNTLM is quite old and unmaintained and it won't correctly relay the new NTLM messages to and from the Active Domain controller. The slightly surprising part was that it did not actually matter what browser I used: all (IExplorer, Firefox, Chrome) apparently used the OS facilities to handle the NTLM messages...

The solution for me was to write from scratch PyAuthenNTLM2 (another module for Apache), because the server was not part of the domain and AuthenNTLM was the only option (modntlm would simply not compile). PyAuthenNTLM2 handles both NTLMv1 and NTLMv2, but is based on mod-python, not on Perl.

Several sites on the web suggest to tweak a (fairly well hidden) security setting in the client OS so that the old NTLMv1 will be used, but I would steer away from that. NTLMv1 is simply totally insecure by today's standards.

SquareRootOfTwentyThree
  • 259
  • 1
  • 5
  • +1 for taking the problem into your own hands, great module – EMI Feb 27 '12 at 15:32
  • For those who would prefer to just let Windows Vista/7 machines use NTLMv1 if NTLMv2 doesn't work, you can change the "Network Security LAN Manager Authentication Level" Local Security Policy setting to "Send LM & NTLM - use NTLMv2 session security if negotiated" (in `secpol.msc`) as per [the instructions here](http://www.sevenforums.com/network-sharing/58238-net-use-doesnt-work-windows-7-computer.html#post528153). – Kit Grose May 28 '12 at 08:54
  • @Kit-Grose That is a terrible piece of advice. It is extremely easy crack your password with NTLMv1. – SquareRootOfTwentyThree May 28 '12 at 09:47
  • @SquareRootOfTwentyThree I'm not using my Apache server for production use—I'm just using it for testing. Is it in any way more insecure than running Windows XP which doesn't use NTLMv2 at all? – Kit Grose May 28 '12 at 23:45
  • @Kit-Grose Sorry, I just saw your comment. XP fully supports NTLMv2 (it's been there since Win95 even), but it accepts and uses NTLMv1 as minimal security level. With Vista, Microsoft simply boosted the default minimum security level that can be accepted for authentication. NTLMv2 have been an option for years, but it was not enforced because of compatibility reasons. WinXP can potentially be configured for accepting only NTLMv2 (eg via Group Policy). – SquareRootOfTwentyThree Sep 15 '12 at 13:29
  • @SquareRootOfTwentyThree: Right, so if I'm understanding rightly the change I'm making reverts Vista/7 to XP-default level security (allowing it to negotiate down to NTLMv1)? That seems a reasonable trade-off for my (very limited) needs. – Kit Grose Sep 17 '12 at 07:28