Commit my stuff to 3.0?

[Andrew Bartlett]

Volker.Lendecke at SerNet.DE wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> > I know why 'only algorithmic' mapping is a pain - we can't do migration
> > from NT, but why is adding algorithmic RIDs a problem here?  (Other than
> > asthetics)
> 
> I do not really like the idea of mixing two approaches. Ok, you can
> make reasonably sure that both do not clash with a high enough
> algorithmic rid base. Hmm. From a functionality point of view, it is
> mainly asthetic. And fearing that we might miss corner cases. Not
> giving anything back from pdb_getsampwnam when the user is not in SAM
> is much more obvious than a user magically popping up.
> 
> > But yes, this is one of the ugliest parts of the unixsam approach.  It
> > also has implications for the 'add computer to domain' priviage.
> > Basicly, we have to decided if unix users not in a SAM backend are in
> > the domain.
> 
> I would vote for 'NO'.

My problem with this is the behaviour change - suddenly these things
that did work won't, and the need for a uid->SID for more than just
smbpasswd users.

For example, to construct a meaninful NT_TOKEN, we really need a
uid->sid mapping for:

force user
force group
guest account
any secruity=share user

And I think we should always have an account mapping onto the 500 and
501, administrator and guest.

> > The problem is that we currently allocate them a SID as if they are
> > members of the domain.  And we need to be able to preserve that
> > allocation, even if we add them to smbpasswd - sombody could have aimed
> > an NT backup tool at us, and we gave the OLD SID as a the owner, and
> > when we 'restore' it's 'gone'.
> 
> I would not see this as a problem. The same happens if you delete a
> user between backup and restore. Messing with the user database kills
> backups even under unix most of the time.

My worry is NAS stuff, and fileservers.  When an admin adds a password,
I'm not sure that they expect a change in SID...

> > Or we have a domain user, who owns files on a workstation.  This user's
> > smbpasswd record is deleted - should we no longer map that SID to the
> > users unix name?  (Quite possibly the answer is yes).  Should users not
> > in smbpasswd be mapped uid->sid->name at all?  Currently we do, and some
> > NAS products use this behaviour.
> 
> My solution for this is mapping users not in the 'rich' pdb backend to
> S-1-5-33-uid (no typo!). This is the newly created 'local unix
> auth'. lookupsid should return 'not mapped', as NT4 would after that
> look up 'local unix auth'#1c... W2k shows the SID in plain text, NT4
> shows 'local unix auth\account unknown'

This could have interesting security implications - becouse each
fileserver will be serving rids in the same RID space, and becouse of
how NT copies ACLs with a file.  When you copy this file back, it's now
got permissions in 'unexpected' groups.  Under NT these groups would be
full SIDs, so be restricted as such - but under this they would map back
to gids, which have a different meaning.

> > We have many of these problems already, but they get worse when
> > allocated RIDs are the norm, rather then the exception.  Perhaps we
> > should move SID->uid and uid->SID stuff into a seperate module?  This
> > was somthing we were looking at for the 'new SAM', but maybe we need it
> > sooner.  (It is not dependent on the rest of the work).
> 
> I remember the word SURS.... ;-) I think this would not help. We will
> never be perfect NT, we will always have rough edges. But at least if
> the behaviour is known and documented, I would be happy. I need to
> *explain* that stuff to people sitting in courses. For this simplicity
> is really important.

Yes, we need a simple solution, but I'm not sure there is one...

Andrew Bartlett

-- 
Andrew Bartlett                                 abartlet at pcug.org.au
Manager, Authentication Subsystems, Samba Team  abartlet at samba.org
Student Network Administrator, Hawker College   abartlet at hawkerc.net
http://samba.org     http://build.samba.org     http://hawkerc.net