Problem: changing password from WinNT workstation 4 SP3

Bernie Kirby bernie at
Sat Nov 28 03:15:13 GMT 1998


I also have this problem. It would seem to be byte order problem
maybe  unique to Solaris2.x In any case, the 'new' password ends 
up being null at approx line 700+ in chpasswd.c, where it calls

		char *pw;
                new_pw_len /= 2;
                pw = unistrn2((uint16*)(&lmdata[512-uni_pw_len]), new_pw_len);

	pw is always a null string.

		As an experiment, I replaced this call with:

			char	buf[100];
			int	i;
			memset(buf, 0, sizeof(buf));
			for (i = 0; i < new_pw_len*2 && i < 100; i += 2) {
				buf[i/2] = (char)lmdata[512-uni_pw_len + i];

			memcpy(new_passwd, buf, new_pw_len+1);

			DEBUG(0, ("new passwd = '%s'\n", new_passwd));

	This isn't a general solution, but it shows the problem.

	You get the 'proper' new password. and no longer get

	check_oem_password: old lm password doesn't match.

	and can now at least proceed...

And on to another problem...
	Latest CVS code checked out a day ago...but the problem has
existed for a week or two..

	smbpasswd -a username...

	in passdb/smbpasschange.c, when adding a new user
	local_password_change calls
	getpwnam(), which returns a static buffer.

	then after the call to         
		smb_pwent = getsmbpwnam(user_name);

	at about line 113, the pwd->pw_uid is now equal to the
	last uid read in the smbpasswd file.
	(remember, we are adding a user, and they don't exist
	in the smbpasswd file yet).
	Thus the new user gets the uid of the last one in the 
	smbpasswd file.

	I don't know, but it looks like it's calling one of the
	getpw*() routines for each of the entry in the smbpasswd
	file and overwriting the static buffer from the first
	getpwnam call. I just made a local copy of the returned
	buffer and now at least the new users aren't getting
	mucked about...

More information about the samba-ntdom mailing list