Problem: changing password from WinNT workstation 4 SP3
Bernie Kirby
bernie at ecr.mu.oz.au
Sat Nov 28 03:15:13 GMT 1998
G'day,
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