The Samba-Bugzilla – Bug 8386
passwords greater than 8 characters supplied to smbpasswd 3.6 don't work
Last modified: 2012-05-16 07:01:50 UTC
Existing passwords in a passdb.tdb seem to work regardless of length. However, when using smbpsswd in samba 3.6 to save a password greater than 8 characters, OS X and Windows clients will get rejected. Interestingly, the smbclient does work.
What platform are you testing this on ? Is it Solaris ? Some UNIXes have a broken getpass() function that limits to 8 characters or less, our autoconf tests should detect this and use our own version instead.
Can you give me more details on how you are reproducing please ?
This is on Solaris Express 11, the latest build. Existing passwords greater than 8 characters work. It's only the new ones I add with smbpasswd that do not work from the Mac or Windows, but they do work with smbclient (on Solaris).
I was having the same problem (Solaris Express 11 and samba 3.6.1). utils/passwd_util.c wasn't including "system/passwd.h" which would have replaced getpass with getpassphrase on Solaris. Maybe includes.h should include the file. Hope it helps.
This is still a problem as of 3.6.4 with Solaris 10.
The output of sotruss shows that smbpasswd is using getpass() instead
of getpassphrase(). The NTLM hashes are derived from passwords truncated
to 8 characters.
Configure correctly detects the existence of getpassphrase(), and as
Katsuya Tomioka noted, the header file system/passwd.h file which would
re-define getpass() with getpassphrase() does not get included in the
source files which use getpass().
In fact, it seems perfectly perverse in that all the .c files that
use getpass() does not include system/passwd.h, and all the files that
include system/passwd.h do not use getpass()!
Modules that use getpass():
# Not sure if these need fixing.
I'm not sure what the comprehensive fix is, but I do confirm that adding
to source3/lib/utils/passwd_util.c creates a smbpasswd executable that
supports getpassphrase(), which in turn, creates correct NTLM hashes
for passwords >8 chars.
Should be fixed in the next non-security release of 3.6.x
*** This bug has been marked as a duplicate of bug 8729 ***