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

[Nicolas Williams]

On Wed, Dec 29, 1999 at 07:33:32AM +1100, Luke Kenneth Casson Leighton wrote:
> 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,
[...]
> 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.

It's not a security risk and it's not a bad 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.

Yes. And if those users also have matching NT accounts in a domain that
is for the same site and purposes as the Unix domain, then I'd like the
Unix uids/gids to be resolved into NT usernames/groups relative to the
NT domain, from the NT client perspective.

This is a particularly situation though and not every organization has
that kind of ono-to-one relationship between Unix and NT domains.

So, the algorythmic mapping is perfectly ok to use. There is nothing
wrong with it except that it hides any equivalence you might have
between a Unix domain and an NT domain, if you happen to have such an
equivalence.

> 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.

Right. If Unix uids/gids can be mapped to domain SIDs+RIDs (because the
equivalence is semantically correct where you are - this is not true for
every org, probably not even most, though most probably want it) then
you can avoid having to think too much about how to achieve the same
restrictions on a access to a file because the same thing will work on
Unix and NT (provided you have ACLs on the Unix side - yes, I know, some
of the ACL semantics will necessarily be different).

> > > 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.

Yes, but that's a name->SID lookup. What about a SID->name lookup when
you don't know what domain the SID is from? If you have a trust
relationship your DC can tell you the SID's domain name and you can go
from there.

This is some out-loud thinking related to my suggestion that the base
side in Samba uid/gid->sid conversions be configurable.

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

Of course.

> > 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].

What's wrong with the shared memory approach suggested earlier, where
nmbd copies incoming, unaccounted for packets in a shared memory segment
that nmblookup, smbd et. al. have access to?

Nico

This message contains confidential information and is intended only 
for the individual named.  If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail.  Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free 
as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses.  The sender therefore 
does not accept liability for any errors or omissions in the contents 
of this message which arise as a result of e-mail transmission.  If 
verification is required please request a hard-copy version.  This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities or 
related financial instruments.