Security Identifier (SID) to User Identifier (uid) ResolutionSystem
Luke Kenneth Casson Leighton
lkcl at samba.org
Wed Dec 29 18:59:15 GMT 1999
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
> > 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
> SID for algorythmic uid/gid->SID mappings.
> > tired.
> > got to get some sleep. that's my excuse, anyway :_)
:) you might have noticed, i got some. sleep, that is :) hur hur.
More information about the samba-technical