Bug 2128 - smbpasswd fails when NTLMv2 is enforced ("Server did not provide 'target information'")
smbpasswd fails when NTLMv2 is enforced ("Server did not provide 'target info...
Status: NEW
Product: Samba 3.0
Classification: Unclassified
Component: Client Tools
3.0.10
x86 Linux
: P3 normal
: none
Assigned To: Samba Bugzilla Account
Samba QA Contact
http://groups.google.com/groups?selm=...
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2004-12-06 16:52 UTC by Magnus Holmgren
Modified: 2012-01-17 17:59 UTC (History)
5 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Magnus Holmgren 2004-12-06 16:52:22 UTC
I've run into the problem reported by Günther Schlegel (see URL).

smbpasswd gives the following output after entering the old (correct or not) and 
new passwords:
---------------
Server did not provide 'target information', required for NTLMv2
rpc_pipe_bind: rpc_send_auth_reply failed.
machine 127.0.0.1 does not support SAMR connections, but LANMAN password
changed [sic!] are disabled
---------------

Version is 3.0.8-2 (Debian GNU/Linux)

Relevant entries in smb.conf:
---------------------------------
security = USER
domain logons = Yes
server signing = Auto
use spnego = Yes
lanman auth = no
client lanman auth = no
client ntlmv2 auth = yes
passdb backend = smbpasswd, guest
client plaintext auth = No
client use spnego = True
client signing = Yes
---------------------------------

With client ntlmv2 auth = no, smbpass (naturally) succeeds.

Changing the password from a W2k client configured to send only NTLMv2 responses 
seems to work. Other client applications, like smbclient, also work.

From the debug output it seems that the client actually receives at least one 
type two response *with* target information. That's another reason to suspect 
this to be a bug in libsmbclient, but it could be ntlm_auth too.

Can anyone reproduce this? Otherwise I'll post logs right away. I can't think of 
any good reason for this behaviour.
Comment 1 Andrew Bartlett 2004-12-22 18:55:20 UTC
The Samba3 RPC server has a very old implementation of NTLMSSP, and as such it
does not support NLTMv2.  This needs to be fixed for a number of good reasons,
but it's complex to hook in the new code from Samba4.
Comment 2 Magnus Holmgren 2004-12-23 10:25:34 UTC
Question: So this is a deficiency/problem/bug in the server/ntlm_auth, not 
libsmbclient? Just wondering why changing passwords from Windows (set to only 
send NTLMv2 responses, I'm pretty sure) works then...  But then again, Windows 
could be cheating somewhere.
Comment 3 TAKAHASHI Motonobu 2005-08-29 10:25:11 UTC
Samba 3.0.14a still has this problem.
Comment 4 TAKAHASHI Motonobu 2005-08-29 10:27:59 UTC
my smb.conf is 

[global]
  client ntlmv2 auth = Yes
  log level = 3
  use spnego = no
Comment 5 Andrew Bartlett 2005-08-29 14:41:29 UTC
This is almost certainly fixed in jra's upgrade to real NTLMSSP in Samba
3.0/trunk.  I'm not sure what version (I'm guessing 3.0.21) it's targeted to
land in however.
Comment 6 Chris Smith 2010-05-12 10:04:30 UTC
Still a problem with samba-3.5.2.

SAMR connection to machine NT_STATUS_ACCESS_DENIED failed. Error was
127.0.0.1, but LANMAN password changed are disabled

It's important because it's the only way to test client/server password change without a Windows box.

Chris
Comment 7 Francis Brosnan Blázquez 2012-01-17 17:59:37 UTC
Just to confirm the problem is still present on samba 3.5.6 as packaged by debian squeeze.

Our samba configuration uses LDAP, and when run the following command it gives reported error:

>> smbpasswd aspl-test -r localhost
Old SMB password:
New SMB password:
Retype new SMB password:
SAMR connection to machine NT_STATUS_ACCESS_DENIED failed. Error was localhost, but LANMAN password changed are disabled

Setting "client ntlmv2 auth = no" as Magnus suggested yields to the same error.