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

[Luke Kenneth Casson Leighton]

On Wed, 29 Dec 1999, Nicolas Williams wrote:

> 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

describe to me the situations in which algorithmic mappings are
acceptable.  i already know about the one where samba is a PDC and you can
only have domain users for that one domain, supported, and no others.


> if you can establish the mappings offline, so to speak (which you claim
> one can, via auto-population of SURS tables - agreed).

... ok, very cool.  another potential convert to db-based SURS tables.
 
> > > 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.
> 
> ?

to explain further.  the algorithm in samba 2.0.x is used in two places.

1) the SAM database in samba is actually created from the unix uid
/etc/passwd (or whatever) pwdb.  unix uids are converted to a RID, the RID
is cappended to the SAM SID, you haev your SID.

2) when _any_ SID comes in, the same rid-uid function is used.  any SIDS
that do not match the SAM SID at the front are REJECTED.

the rejection bit is what i object to about this algorithm.

if a SURS table existed, (db implementation) we could map, say,
SAMBASERVERDOMAIN\user1 to uid500, and DOMAIN2\user1 to uid501, and
DOMAIN3\user1 to uid502, where uid500 has a unix pw entry name of user1,
uid501 has D"user1 and 502 has D3user2.  slightly painful, but not as
stupidly limiting as thininkg that i think remote users exist on POSIX!

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


yes, yesm, and eys some more.  oops i'm not going to spell-correct that, i
like it :-)

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

i have no problem with that, in fact i encourage it.
 
> > 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?

agreed.

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

*whew* i was worried for a minute, there.  you're not just giving up on
me, are you, you do realise why i think it's a bad idea?  btw thanks for
going at this with me, and you too, jeremy, i know this isn't exactly a
trivial area.


> SID for algorythmic uid/gid->SID mappings.

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

:) you might have noticed, i got some.  sleep, that is :)  hur hur.