Security Identifier (SID) to User Identifier (uid) ResolutionSystem
Luke Kenneth Casson Leighton
lkcl at samba.org
Tue Dec 28 20:13:52 GMT 1999
On Tue, 28 Dec 1999, Jeremy Allison wrote:
> Luke Kenneth Casson Leighton wrote:
> > 2) multiple samba servers as members of the same domain need
> > same-user-name-same-smbpasswd locally on each server, and they _still_
> > produce different SIDs for the same damn username, which i am sure is a
> > security risk, i just can't think it through clearly, it's that brain-dead
> > and complicated an issue.
> 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.
when the NT user logs in to the samba server (SMBsesssetupX), we currently
verify the user against the remote PDC (security = domain). the SID for
the user is therefore S-1-5-21-remote-pdc-NNN. we use "map username" to
map to a unix user, and use getpwnam() to turn this into a uid.
when the NT user accesses a file, we currently take the uid (obtained
above), put it through pdb_user_rid_to_uid() to generate MMM, and then
return S-1-5-sambalocal-SAM-MMM as the SID for the user.
_each_ samba server that is a member of a domain does this, resulting in
different SIDs for the same remote NT user as they access the file
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).
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,
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).
an SMBsesssetupX with the name of the server as the domain name must go to
the pocal SAM database not the remote one, even if "security = domain" is
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?
> Think about this (some more :-).
i've been doing nothing else for the past 5 days, pretty much.
> If this is a security hole then NT security is *completely*
> broken (hint. It's not :-).
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.
More information about the samba-technical