samba - Feb 2002 - BUG: "update encrypted" and "username level" corrupts smbpasswd file

It took me a little while to figure out what was going on here ...
We're trying to migrate a site from non-encrypted to encrypted
passwords using the "update encrypted" option.  Apparently,
this causes problems when "username level" is set greater than
zero (it's set to 15 in our implementation)
We've been having a lot of problems when we turn on
encrypted passwords, and I think I finally know why.

Let's take an example:
User joes has an entry in the password file with a valid password and
can thus log in fine when "encrypt passwords = no".  We turn on
"update encrypted" a few weeks prior to switching to
"encrypt passwords = yes" and joes logs in may times during those
weeks, so joes should have an encrypted password in the smbpasswd
file and we can switch to encrypted passwords with no problems, but it
doesn't work and joes can't log in.  Here's what I've found:
In the unix password file, the name is "joes"
In the smbpasswd file, the name is "Joes"
Trying to update the password from SWAT causes errors and fails.
Trying to update the password from unix command line with smbpasswd
results in error: "The smbpasswd file is corrupt, user Joes does not
exist in the unix password file"
Most frustrating is that attempting to use "smbpasswd -x" results in
the
same error and I have to manually edit the smbpasswd file to remove
the entry.

So ... the upshot of the whole thing is that setting "update
encrypted" on
when "password level" is greater than 0 can "corrupt" the
smbpasswd
file.

Unfortunately, I don't currently have a test environment where I can narrow
this down further, but I had to get it figured out for this client so I could
fix it.
We have a workaround: manually get smbpasswd up to date, but I thought
I'd pass this on so the samba team could look at it.
-- 
Bill Moran
Potential Technology technical services
http://www.potentialtech.com