Security Identifier (SID) to User Identifier (uid) ResolutionSystem

[Luke Kenneth Casson Leighton]

On Tue, 28 Dec 1999, Jeremy Allison wrote:

> Luke Kenneth Casson Leighton wrote:
> > 
> > > They create different SIDs because they are *DIFFERENT USERS*.
> > 
> > if they are different users, then they should be in private/smbpasswd, not
> > verified against the PDC.
> 
> No. Not true. We verify against the PDC as a convenience. The
> real user list remains in /etc/passwd (or the nsswitch equivalent).

i assume that it is understood that regardless of whether the PDC is used
to authenticate the user or whether private/smbpasswd is used to
authenticate the user, the NT username (or, to be more precise, that NT
user's SID) is expected to be resolved to a unix user (or, to be more
precise, a unix uid) in, as you say, a real user list in /etc/passwd (or
nsswitch equiv.).

this is a given assumption, thanks for raising this point.

now.  if you authenticate against the PDC, the SID associated with the
real user (let's say that it's in /etc/passwd and the uid is 500) is
S-1-5-remotepdc-sid-NNN.

converesely, if you authenticate against the local private/smbpasswd SAM
database, the SID associated with the real user (uid 500) is
S-1-5-sambalocalsam-sid-MMM.

these are, as you say, the same real user (to the local POSIX system on
which samba is running: yes i understand this issue, too, jeremy :)

...BUT... they are _different_ NT users.

it is our responsibility, as file server implementers (NT-compatible ones,
at that :-), to maintain this distinction (the NT one) as _well_ as
obeying POSIX conventions.
 
> > this means that instead of the NT client going to the PDC to resolve the
> > SID for a user (LsaLookupNames to the PDC) the NT client comes to us to
> > resolve the SID (LsaLookupNames to the samba server).
> 
> Which is exactly what the need to do, as the SID they are
> using is relative to the Samba server they have mounted,
> and cannot be used anywhere else.

well, it can't be used anywhere else because we have created that
restriction by mapping a SID S-1-5-remotepdc-NNN to a real unix uid and
then mapping it to a SID S-1-5-localsamba-sam-MMM!

so, if this is acceptable behaviour, then yes: it's exactly what we need
to do, and yes: it cannot be used anywhere else.

where i have a real problem with this is that i do not consider it to be
acceptable to map from a remote SAM SID to a real local unix uid and then
to a _different_ [local] SAM SID.

 
> > my question is, therefore, what the heck are we thinking, and what was it
> > again that we were smoking when we discussed this fifteen months ago,
> > jeremy?
> 
> It is exactly the correct thing to do for file system users.
> 
> > additionally, i don't believe that samba 2.0.x can properly distinguish
> > local users from remote users in SMBsesssetupX, at the moment (i think i
> > only recently properly implemented this in SAMBA_TNG when i implemented
> > get_any_dc_name(), i'll have to check).
> 
> It cannot distinguish them because POSIX doesn't distinguish them.
> 
> THERE ARE NO REMOTE USERS IN POSIX.
> 
> My God luke, how many times do I have to shout this ? Last time
> I mentioned this you agreed with me. Why are you bringing this
> erroneous assumption up again ?

because i understand that there are no remote users in posix.  i _do_
agree with you.  i am not making any erroneous assumpions.

what i am desperately trying to get you to appreciate is that we are
making a really big mistake by mapping from remote SAM SID to real local
POSIX uid and then to a different SAM SID.

> > if this were to be implemented, how would we create ACLs to distinguish a
> > local user login (SID of local user = S-1-5-localsmbpasswd) from a remote
> > user login (SID of remote user = S-1-5-passwordserver=someserver with
> > security=domain set), when the algorithmic function we are using can only
> > deal with one SID?
> 
> We don't. Pure and simple. For the reason that a "remote login user"
> DOESN'T EXIST ON A UNIX SYSTEM.

i know.  and this fact [remote users don't exist on UNIX, only local uids]
does not change a thing.  you can still map local uids to absolutely any
SID that you desire, and get away with it.  why?  because SIDs don't exist
on Unix systems.  it's something we choose to create.
 
> > i've been doing nothing else for the past 5 days, pretty much.
> 
> But you keep bringing up the same issues ! I'm starting to think
> it's not worth discussing this with you, you never seem to get it !

ok, i have been trying to think of a way to appreciate what i am trying to
tell you.

think about this: why are we bothering to map uids to SIDS in ACLs,
anyway, even with the 2.0.x scheme?  we can't do this, because, according
to your own argument, the concept of "remote users" doesn't exist on a
Unix system.  SIDs do not exist.  remote users do not exist.  therefore,
we cannot even _create_ SIDs because they are meaningless to the Unix
system that samba is implemented on.

please, therefore, assume that _i_ am the one arguing this point, and
please come up with an argument that is sufficient to convince me that the
use of, or the concept of SIDs can be used, at all in Samba.


> > NT doesn't authenticate users against the remote PDC's SAM and then
> > generate ACLs for those users from its local SAM database, which is what
> > is implemented _right now_ in 2.0.X with "security = domain".
> > 
> > this is what i am objecting to, more than anything else, and it's all due
> > to the use of the pdb_group_rid_to_gid() etc functions.
> 
> I will discuss any and all of this further with you, when
> you tell me how to distinguish between a local and remote
> uid_t or gid_t on POSIX.

_if_ it's actually necessary to distinguish between local and remote
uid/gids on POSIX, and there are schemes outlines that make it unnecessary
to make such a distinction (definitions of SURS tables):

http://cb1.com/~lkcl/cifs/draft-lkcl-sidtouidmap-00.html, section 4, "Use
of multiple SURS tables".  paragraph 6.  this requires the use of two SURS
tables, one for /etc/passwd and one for the NIS database.  the local SURS
table is maintained manually by the same administrator that maintains the
local /etc/passwd table.  the remote one is maintained in in any other
[suitable] fashion.

quote:

It may be difficult to determine whether a Unix user is in /etc/passwd
or in the remote NIS database, particularly as the implementation of
getpwnam() and getpwuid() (or equivalents) is usually designed to hide this.
Under these circumstances, the SURS tables themselves MAY be used to
determine which uid is actually in which Unix database (local or remote).
If this is required, then the local SURS table MUST be populated with all
the required entries in the local /etc/passwd database.  The assumption is
that if a SID or a uid is resolved in the local SURS table, then it can
be deduced that the the uid must exist in the local /etc/passwd database.