Inoltra: Re: Why machines in passwd anyway? [was Re: NT machine accounts in FreeBSD?]

[Elrond]

On Tue, Aug 15, 2000 at 02:16:55AM +1000, Simo Sorce wrote:
> Quota Peter Samuelson <peter at cadcamlab.org>:
> 
> > 
> > [Simo Sorce <simo.sorce at polimi.it>]
> > > So we need a centralized point to store NT
> users/machines, rihgt?
> > > what about smbpasswd/ldap?
> > 
> > My point exactly.  The way I interpret Elrond's
> response: "fine, sounds 
> > good, where's your patch?"  In other words, it's not

Well, that was somehow my point...
but... see below...

> worth changing
> > unless someone volunteers....
> > 
> > > Do we really need a Unix user for trust-accounts?
> > > Do anything related to trust account need a Unix
> user?
> > 
> > No, but from the NT perspective, a list of users is
> expected to include
> > all the trust accounts.  That means the Samba function
> for enumerating
> > users needs to enumerate trust accounts as well.
> > 
> > Here's my ideal world:
> > 
> > * "encryption = no" --> this means there are no trust
> accounts to worry
> >   about.  Keep the status quo, use libc/NSS, pull RIDs
> out of thin air.

This doesn't realy depend on encryption = yes, but the role
of samba... If it's playing PDC/BDC, trust accuonts make
sense, otherwise they don't make sense.


[...]
> > * anyone who needs the UID uses a separate lookup
> function sid2uid or
> >   whatever (I think this part is already in place,
> actually) and only
> >   *then* do you bother with
> >   - username map
> >   - getpwnam and friends
> >   - groups
> >   Then this information is cached by the sid2uid
> function somehow.

The sid2uid-function is one of the big issues... Maybe some
remember the long talks about SURS on samba-technical...
That's all about it...

The whole SURS-stuff is quite complex. From this
description here, it sounds quite easy... but there are
other problems: If samba is trusting another domain, users
from that domain need to be mapped to local unix users. So
the sid2uid-function must also handle sids from domains, it
doesn't control and the other way around. This all gets
complicated, if you want stuff like "domain group map" to
work and so on. And another story are groups, because
groups and aliases also need RIDs, so you realy have a
sid2unix_id, where a unix_id is either a group with a gid
or a user with a uid.

And at the end, current TNG users will want a smooth
transition method. (They will not like it to setup their
domain completely from the beginning)


> > 
> > I think, on the whole, this would be more efficient as
> well as
> > eliminate the pesky machine$-in-/etc/passwd problem.
> > 
> > Unfortunately it also means a fair amount of coding,
> in what some
> > consider the armpit of the Samba source, passdb/*. 
> Coding by someone
> > who cares enough about this stuff to do it.  Which
> Elrond doesn't,
> > because he has more important things to do to help
> stabilize Samba.
> > (After all, the status quo *does* work, it's just a
> little annoying for
> > the administrator.)

I'm now and then thinking about the whole SURS-story,
because I don't yet have something like a "master plan" on
how to use SURS in TNG. One of the issues are, that the
HEAD developers want SURS to be external in winbindd and so
on.

> > Peter
> > 
> 
> OK, here is my patch to strip out workstation accounts
> from passwd.
> 
> It, works for me (Linux-Samba PDC <-> NT4-SP5)
> Anyone want to test it??

I've read your docs and some of the patch.

Don't misunderstand my following stuff, I don't want to
displease you.

The diff is for 2.0.7. This version isn't currently any
more realy "up to date". The next official major release
will be quite different. And TNG is anyway completely
different.

If you have read the above about SURS, that's the other
problem. The SURS-techniques in TNG aren't in any form in a
fashion that neither Luke nor me like. But a lot of thought
is needed in this area... (I hope, I get the time to think
this through and write up something...)

I'm currently thinking, wether you might send a short note
about your patch to samba-technical at samba.org, so the
HEAD-developers could take a look at it... don't know yet.

If you write there, include some short description of the
problem, you're trying to fix, because most of the poeple
on that list don't follow this list.

But don't be disgruntled if you get to hear some similar
response than mine.

> Feedback, really welcome!

Well, you got mine... I guess, you wont like it...

> Simo.

Thanks anyway for your interest in all that.


    Elrond