samba at aquasoft.com.au
Tue Feb 24 22:20:37 GMT 1998
Your analysis of the issues is clear and seemingly comprehensive, as per
your usual style.
One issue you did not address is the inherent dynamics of change.
What has inertia? What could gain support of the Unix/Linux community and
what effort would that take?
Also, what is your estimate of the time frame before an acceptable
solution may be available?
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).
While in London, I spoke with Luke about this and the possibily of a samd
(SAM Daemon) that maintains a Unix equivalent of the NT SAM and SECURITY
database files in a suitably secure format. I suspect this is still a good
option to protect the database from prying eyes. The samd could have an
API that Samba could call into.
This does not address your concern of the mechanics of implementing a
synchronised password change from a Windows client system. The key to
success of Samba has been the fact that it does NOT require ANY
third-party add-on software for the MS Windows client. 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.
Sorry if I seem a wet blanket here, that is not my intention.
Your efforts are appreciated very much.
John H Terpstra
More information about the samba-ntdom