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 anticipation.
Me too
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 to root. 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@felsted.essex.sch.uk