paul at argo.demon.co.uk
Tue Feb 24 23:10:29 GMT 1998
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
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*.
More information about the samba-ntdom