> What we want to do, is let the user log into an
Linux machine (SuSE8.0Pro) -
> authenticate their username and password from the NT user database, and then
> map their user space to a drive on the Linux machine.
I can give no advice but I listen in great
I certainly have had no wish to duplicate all our
accounts on the
LINUX box together with shadow password files and various hacks to
keep passwords synchronised.
We are doing this successfully, but in the other direction, i.e. the
master authorisation system is Unix and we authenticate Windows systems
against that. For plain Samba mounts, it's fine with no smbpasswd files:
one single Unix authorisation "passwd file" system has worked for five
years BUT we have had to enable-plain-text-password on all Windows
machines, a different registry mod for each issue. No problem, actually,
the only hacks have been pupils using Cain to decode local .pwl files, and
that's their problem, not mine, it can only affect people who use Windows
machines, and only 95/98/me too.
But last year we put in a w2k/wts server to use with Rdesktop, and to
authorise rdesktop logins to this we had eventually to bite the bullet,
copy the password file system into a parallel "smbpasswd" file and insert
a new "passwd" command that calls both the old passwd and smbpasswd so as
to keep the two password files (both of course on the Unix server) in
synchronisation. The w2k server is "joined" to the Samba server's domain,
and is definitely and rightly subservient to it!
Since the parallel file has passwords that are reversibly encrypted, our
security is now lower, but that's inevitable if people want to use Windows
software. Not much lower, really, as the smbpasswd file is only accessible
Sometime during the next five years I might change the root password from
the dictionary word it has been for the last five or ten.
Christopher Dawkins, Felsted School, Dunmow, Essex CM6 3JG
01371-822698, mobile 07816 821659 cchd(a)felsted.essex.sch.uk