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

[Nicolas Williams]

On Wed, Dec 29, 1999 at 09:41:50PM +1100, Luke Kenneth Casson Leighton wrote:
> > > ... 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.

No. Algorythmic mapping is ok to use all the time. Table lookups are ok
if you can establish the mappings offline, so to speak (which you claim
one can, via auto-population of SURS tables - agreed).

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

Yes. We don't have any interest in Samba PDCs where I work, thus we have
no Samba PDCs, no Samba SAMs (i.e., no smbpasswd file).

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

This is true only for Samba PDCs. In the context of XAD (which is how
this whole thread got started in the first place) Samba wouldn't be
responsible for maintaining the SAM directly: XAD would be, and Samba
would simply provide the LSA RPC and MS RPC interfaces to XAD.

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

Right. Again, put XAD (or AD) in the context and we're in agreement.

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

[...]

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

Yes, but if you have ACLs on the unix side, why not support them where
possible?

[...]

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

Ok, so forget my suggestion about letting the Samba admin provide a base
SID for algorythmic uid/gid->SID mappings.

> tired.

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

Heh.

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.