Synchronising passwords

[Paul Ashton]

At 09:20 25/02/98 +1100, Samba Bugs wrote:
>Also, what is your estimate of the time frame before an acceptable
>solution may be available?

It depends what you want. Many people will be happy to require the
user to generate their smbpasswd on unix first, either via a
special program, or via a web browser. There is no absolute
necessity to implement compatibility. The time frame for that
solution is 0 - somebody has already written a CGI script to do this
ISTR.

What about all the people who don't want their users to do anything
at all? Well there are two immediate solutions that require hardly
any effort but reduce security.

1. Ignore the password and force the user to change it when they
   log in, store the new smbpasswd entry.

2. Tell your users to login as "USER-UNIXPASSWORD" with any
   password. Samba-ntdom will extract the second half of the
   username, crypt(3) it and compare with /etc/passwd. If it
   matches, generate an smbpasswd entry and log them in.
   Their password goes over the net in the clear but if it
   used to anyway...
   To make it a bit more secure, force them to change it as
   well (but then it won't match /etc/passwd anymore, but
   that isn't a such a bad idea...).

>My personal preference is to make the password synchronisation Unix
>centric, thus PAM could be a suitable vehicle even given maintenance of
>both /etc/passwd and /etc/smbpasswd files. I am confident that the
>Unix community will be __unwilling__ to consider a change away from
>/etc/passwd (and it's friends).

That's fine but it can only happen at password change time. Otherwise
a client modification is required to get the plaintext password.

>I can not help but
>fear the worst should we now change that by requiring a "Samba
>proprietary" password change/authentication system for client platforms.

We don't have to *require* it. As long as people can work without
it and having the more elegant/secure, yet client modifying authentication
package as an *option*.

Paul