> Date: Wed, 27 May 1998 19:55:04 +0200
> From: Detlef.Lammermann@er.materna.de (Detlef Lammermann)
> To: jallison@whistle.com, samba@samba.anu.edu.au
> Subject: Re: password sync in 1.9.18p4
> Message-ID: <9805271755.AA12092@helena.er.Materna.DE>
...> 2) In a really old digest (1179 from Wed, 15 Jan 1997) I saw some part of a
> discussion focussing the same topic. What's about this approach?
>
> > From: Don Gaffney <gaffney@emba.uvm.edu>
> > To: Luke Kenneth Casson Leighton <lkcl@cb1.com>
> > ...
> > I've played w/ jeremy's little DLL as well. What you're
saying is that
> > this mechanism can (or does) send a NetUserPasswordChange smb packet
over
> > the net to a remote LANMAN server? Yes?
> >
> > So this can provide a way to sync passwords changed on NT with a
> > SAMBA server. OK. This isn't too bad to do, jeremy's DLL could
open
> > a named pipe to SAMBA and SAMBA could do the rest: change the unix
> > pw file and the smbpasswd file.
I'm no longer working on the password sync problem, and that project
has been thoroughly killed by my last employer. Actually it was really
dead before it got started, but at least I learned a thing or two:
(1) if you are lucky enough to be in the U.S., use KerbNet - this is
_the_ solution to the problem. It actually solves many problems, all
worthy of correction. See www.cygnus.com for more information.
(1a) if Kerberos is a problem, and you are using NIS, try NIS-GINA
from Nigel Williams; see http://www.dcs.qmw.ac.uk/~williams/ or
Doug Scoular's approach at http://www.arch.usyd.edu.au/~doug/gina.html.
Both of these may require some work for use in your environment; there
are more pointers to GINA information at
http://web.mit.edu/cartel/ntgina.html.
(2) if you are a scary-potential-threat-to-U.S.-security user, like
Detlef, then you can either (a) wait for Luke's NTDOM code to fix this
problem or (b) try a commercial product like P-Synch; see
http://www.m-tech.ab.ca/products/ for more information.
(3) many projects are started without the intention that they ever
actually succeed (this is a common truth, but I didn't quite "get
it"
until my late 20's, which is to say, rather recently).
(4) given item 3 it is important that one chooses projects carefully;
it is good to decide ahead of time whether the 'destination' or the
'journey' is more important, and act accordingly.
All of that being said, Jeremy's passwdchange DLL (see SAMBA Digest
1125) can get the NT username, new plaintext password and RID. If it could
provide the old password as well (any idea Jeremy?) then, the DLL could be
modified to act as a smbpasswd client in a fairly straight forward manner
(this is a lot easier with the new smbpasswd code than it was last year,
at that time a second daemon, or modification of the samba source, would
have been required).
The other thing I don't know about is the return value for
PasswordChangeNotify(); I don't know what errors if any can be passed
back to the password change dialog if smbpasswd balks or is unavailable.
Any idea on return codes Jeremy?
Finally, I'm not sure if this mini-project still represents an important
piece in the Samba-NT puzzle given Luke's NTDOM work, the GINAs, and
KerbNet. My own requirements in this area were obviated by KerbNet.
While I truely would have enjoyed helping on the other projects (sorry
Luke, Nigel, Doug), I reached my destination, stepped off the bus and into
the cacophony of the street.
-Don