Commit my stuff to 3.0?
abartlet at samba.org
Sun Oct 13 11:03:01 GMT 2002
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
For example, to construct a meaninful NT_TOKEN, we really need a
uid->sid mapping for:
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 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
More information about the samba-technical