PAM-NTDOM: Compile Errors

[Simo Sorce]

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
> versions?

I agree with Paul and don't care at all if M$ products will recompile
easily.
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
M$ product?
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.
> 
> Paul.
> 
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
team.
Simo Sorce.

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!