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

[Luke Kenneth Casson Leighton]

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

that is a reasonable configuration.

> 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

only in the very specific situation that you describe.  if other sites
require different, more complex configurations, then ithe [particular]
algorithmic mapping is just not enough.

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

ok, there is a distinction between creating a SAM and mapping between SAM
SIDs and uids.

the algorithmic approach does both jobs, and what you just said tells me
that you are confusing the two tasks.

_even_ if you use a SURS database table, samba will _still_ need to have
an algorithmic mapping to create SIDs in its own SAM, from uids/gids,
because that's the implementation we choose.  i have no objection to this:
it maintains backwards-compatibility and heck, what else are we going to
use to create SIDs for the SAM for which we are responsible?

[actually, the answer to this questioin is, if you are using ldap as the
back-end database, the SIDs can come from the same ldap db you get the
uids from.  but if you are using private/smbpasswd, smbpasswd doesn't
store rids, only uids, so you use the rid-uid mapping to create the SID].

at present, we use the same algorithm to map _any_ known SID to a uid, by
discarding anything we don't know about, and that's what i object to.

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

well, you don't really need ACLs unix-side, jeremy has already implemented
a system that maps NT security descriptors to ugo/rwx traditional file
permissions (plus some of the create mode / create mask / create dir mask
/ force group share options, i hope, to create some of the more obscure NT
bits that john was talking about in aearlier emails).
 
> > > > 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.


correct.  just like NT, if you can't contact the DC for the SID, you get
"unknown" in the display stuff, and the SID in the security descriptor is
ignored because it's irrelevant, anyway.


tired.

got to get some sleep.  that's my excuse, anyway :_)