Commit my stuff to 3.0?

Andrew Bartlett abartlet at
Sun Oct 13 11:03:01 GMT 2002

Volker.Lendecke at SerNet.DE wrote:
> 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
Manager, Authentication Subsystems, Samba Team  abartlet at
Student Network Administrator, Hawker College   abartlet at

More information about the samba-technical mailing list