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.
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 [global] 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. Chris
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.
looks a bit like several different issues are mixed up here in the comments. The reported issue is probably fixed. If you still see an issue with the latest 4.11 release, please discuss this on the mailing list and eventually file a bug report for it.