PAM-NTDOM: Compile Errors
simo.sorce at polimi.it
Tue Jul 11 07:52:50 GMT 2000
I was a little scared about replying on this argument to Luke,
but as a Samba/Unix user I think a comment on this must be made.
Paul J Collins wrote:
> >>>>> "Luke" == Luke Kenneth Casson Leighton <lkcl at samba.org> writes:
> >> I never meant to imply that it was. Let me give a
> >> bit of history here. Luke and I (and others) have over
> >> the months and years had discussions over issues
> >> similar to this. Luke has in the past wanted to make
> >> UNIX into NT in every aspect. Not necessarily from a
> >> services point of view, but from an architectural
> >> point of view.
> Luke> both. the possibility of being able to tell microsoft,
> Luke> here, install these services on this version of linux, with
> Luke> these libraries, then hit "compile" on your office msdn
> Luke> development environment, and you will get a native linux
> Luke> office suite.
> First of all, Microsoft Office running on a bunch of Windows-emulating
> services (would CSRSS.EXE be one of these?) is not "native". In a
> similar fashion, a Unix app running on cygwin and using X for its
> display is not really "native" either. I follow the Wine project a
> little, and the things they have to do in order to run Windows
> binaries lift Wine a large step above being a toolkit.
> Second, I don't understand why this is a useful goal. Programs such
> as Emacs have had difficulty mixing well with NT (e.g. NT's primitive
> process model; okay "different" process model); why should the
> converse not be true? And if you follow that approach to NT/Unix
> integration, why not just drop Samba, implement the Win32 API (Wine!)
> the NT system traps and suggest that Microsoft recompile SRV.EXE, et
> al. on Unix?
> Which brings me to my next point. Office and such rely on a number of
> chunks of software, updated versions of which these applications
> frequently install themselves. One example that springs to mind is
> the COM/OLE libaries. Do you reimplement those, or use Microsoft's
I agree with Paul and don't care at all if M$ products will recompile
I want a stable platform and avoid especially as possibile the bad
design of infrastructure that M$ services and programs often provides.
> >> I disagree. Not that I think one is better than the
> >> other. I simply think Samba is an interoperability tool,
> >> and not an operating system.
> Luke> samba requires support from the OS it is running on. we can
> Luke> provide a mapping between NT and unix worlds as best we can
> Luke> [and will have to continue to do so].
Here again, If I want the same way M$ do things than what better than an
Honestly I choose Samba because it runs on a proven
stable/maintenable/understandable/customizable platform as Unix is and
don't want to return to crappy way M$ build their software.
> One example of Samba meeting the underlying OS with some unease is in
> the area of utmp/wtmp handling. As I recall, almost every Unix is/was
> a special case.
> Luke> direct support from the underlying OS to provide that
> Luke> interoperability - e.g a filesystem that provides Unicode
> Luke> direct-to-disk - would be of enormous benefit.
> I'm pretty sure that ext2fs on Linux can store UTF-8 filenames; is
> UTF-8 just "not good enough" (both in this case and in general)? Can
> other Unix filesystems handle UTF-8 in a useful fashion?
> Luke> *shrug*. pam_ntdom is not a high priority for me. plus,
> Maybe not, but it has a user base, and it is a priority for them.
> Luke> the way that PAM works makes it difficult to securely
> Luke> provide the exact semantics of nt authentication.
> I'd like some details on this; if it's been written up, an URL. I've
> found it difficult to locate documentation for PAM in the past.
> Luke> so, for those people who have been asking, i tell them that
> Luke> pam_ntdom is superceded by winbindd.
> I hope this doesn't sound sarcastic, but is it safe to assume that
> winbindd is close to a "final solution", or is there a chance of it
> being abandoned in the same fashion as pam_ntdom has been?
> This is a bit of a ramble. Hope some sense shines through.
I've tested and used pam_ntdom and it was a really good tool?
But going a little further I really dislike the way password are stored
and transmitted in current releases and dislike also the fact (with
pam_ntdom) that my unix account need to have their password stored in M$
format (and winbindd will follow this scheme).
A simple way to do synchronization between the two worlds is really a
need, but the solution may also be to change M$ side. (At least Kerberos
would be an alternative but the way they implement it, is really a
threat to us)
I tested NISGINA for example and it was not to bad.
Would it be so difficult to implent a replacement of the msgina dll with
a sambagina that would permit to use passwords the way unix does?
With the best wishes for the optimum work done untill now by the samba
P.S: Excuse my bad english.
Simo Sorce - Integrazione Sistemi Unix/Windows - Politecnico di Milano
E-mail: simo.sorce at polimi.it
Tel.int: 02 2399 2425 - Fax.int. 02 2399 2451
Be happy, use Linux!
More information about the samba-ntdom