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

[Luke Kenneth Casson Leighton]

On Tue, 28 Dec 1999, Nicolas Williams wrote:

> On Wed, Dec 29, 1999 at 06:39:51AM +1100, Luke Kenneth Casson Leighton wrote:
> > On Tue, 28 Dec 1999, Nicolas Williams wrote:
> > 
> > > 
> > > Luke/Jeremy,
> > > 
> > > The algorythmic mapping of uids/gids<->sids in Samba works fine as it
> > 
> > well... not really.  it's very brain-damaged.
> > 
> > 1) it excludes S-1-5-32 so you can't map any BUILTIN groups such as
> > Administrators and "Account Operators" etc.
> > 
> > 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.
> 
> Some context here: where I work we have only NT DCs and NT fileservers;
> our Unix fileservers also run Samba so that users can access their Unix
> home directories and some application-specific Unix directories from
> their NT workstations. Thus there is no smbpasswd file here.
> 
> So, if you have no Samba DCs and thus no smbpasswd you have no problem.

welll.... the LsaLookupNames calls end up coming to each indivcidual samba
server to resolve ACL components, instead of to the PDC.

i'm not sur that this is a security risk, but it's certainly not a good
idea.
 
> As for Samba DCs for the same domain generating different SIDs for the
> same entity, I see that it works, now, but it's silly. Have a master and
> let the others sync to it instead. Of course, that only works if all the
> *nix hosts running Samba as members of that domain should have the same
> /etc/passwd|NIS domain|whatever so that the same uids/gids mean the same
> users/groups on all those *nix servers; otherwise the current scheme has
> to be continued.

... ok.  the only reason that you might want all the *nix hosts to use the
same uids/gids is to maintain consistency to unix-only users.

part of the SURS specification states that if you do _not_ want this to
happen (e.g you have different NIS domains) they you MUST use different
SURS tables, one for each NIS domain.

this allows consistency from an "NT" view, with SIDs, to be presented to
"NT" users, whilst still maintaining a brain-dead or even a requirement
that two separate NIS domains be used, separated, etc., for organisational
or recent merger/aquisition or just plain dumb reasons.

you can then make decisions based on ACLs / SIDs on the "NT" view to
maintain any restrictions that "NT" users follow (e.g the sales people
from one of the two merged companies aren't allowed access to files on the
engineering dept of the other company), and it all works.... even though
in the *nix world, you're completely screwed and have a different issue to
sort out, there.
 
> > there are situations, however, in which a client will go direct to the SAM
> > database of the server that owns the SID.
> 
> So, if there is no trust the lookups would be direct? OTOH, how could a
> client map a SID to a domain if the client does not belong to that
> domain and that domain is not trusted by the client's domain?

you can still grant remote users in completely foriegn domains (including
workstations) the rights to use/view/rwxblahblah files through the
security tab settings.

i _presume_ that the local NT client maintains a cache that maps the
workstation SID to a name.  i'm just checking, with rpcclient, whether
asking a server to resolve a workstation name returns meaningful info.

again, with the current scheme (2.0.x), workstation SIDs are excluded from
the mapping.

 
> > >  - implement SURS
> > 
> > by definition, both the SURS database and the algorithms are SURS tables.
> > it's just that using algorithms is a really bad, restrictive and
> > unecessarily restrictive, idea.
> 
> Doh. Sorry. I meant a SURS algorythm based on table lookups, rather than
> algorythmic mapping.

:) i know.  i'm being fussy, so that other people who may read this later
don't get confused.  you know what you meant.  i know you know what you
meant.  :)
 
> > >  - a share-wise parameter "guid2sid base sid" whose value is either a
> > >    SID, or a NetBIOS host/domain name
> > 
> > i like this slightly less.
> 
> It's the same thing of which you said "hmm... interesting" :)
> 
> I can see that you might not like using a NetBIOS name as the SID
> reference, as that's not secure. OTOH, you guys did end up adding
> automatic DC finding via NetBIOS just the way MS clients do it. Besides,

yeah, and we can't use it because the UDP 138 response goes back to port
138, not to the requester's port, dammit!

so we would need to move nmbd UDP 138 code into smbd, or create some means
to get UDP 138 responses back to the requester.  or have a port 138
redirector to which both nmbd and smbd can connect and have UDP 138
requests and responses sent on their behalf, using the MAILSLOT name as
the means to identify who to send responses back to.

[same thing as nmb-agent, using mailslot name instead of the nmb trn id.
or maybe using SMB fields in the UDP 138 traffic.  except i know andrew
doesn't like the agent approach].

> > i'm thinking, actually, more along these lines:
> > 
> > > int 		surs_sid2unix(surs_handle* handle, sid_t sid, gid_t **
> > gid, uid_t **uid);
> > 
> > the reason for this is that SIDs can be mapped to either a uid _or_ a gid.
> 
> This is why I had an int return value to specify success or failure+a
> reeason. If you try to map a group SID to a user you shuld get an
> error. Besides, the code calling SURS should be able to determine the
> SID's type.

weeelll.... not necessarily!  that's stored in the SAM database (the SID's
type).

> Hell, the current algorythmic mapping functions could probably be
> separated into their own .so...

yep.