The Samba-Bugzilla – Bug 2128
smbpasswd fails when NTLMv2 is enforced ("Server did not provide 'target information'")
Last modified: 2012-01-17 17:59:37 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
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.
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.
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.
Samba 3.0.14a still has this problem.
my smb.conf is
client ntlmv2 auth = Yes
log level = 3
use spnego = no
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.
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.
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.