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

[Luke Kenneth Casson Leighton]

On Wed, 29 Dec 1999, Jeremy Allison wrote:

> Luke Kenneth Casson Leighton wrote:
> > 
> > 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.
> 
> That's where we differ. We can only allow this if we have a
> mapping table. You want one. I don't. That's the core of
> this argument.

ok, i think we've worked out what's going on.

you don't want samba to be a full nt domain interoperating system.  i
agree: a SURS table that stores any SID/uid mapping for the lifetime of
those SIDs and uids is NOT necessary if you don't want samba to
interoperate fully in an nt domain environment (defined as multiple trust
relationships etc).


> > 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!
> 
> And what happens when these account databases get (separately)
> updated. If people forget to update the mapping table you
> are *hosed*. Admins will burn you in effigy for designing
> this.

delete the table.  it will get auto-created.  any admin that decides to
modify a uid from one user to another uid has a serious set of headaches
coming to them.  any admin that's crazy enough to go hacking the SAM
registry needs to be fired and never allowed near regedit again,
especially in a production environment.  [regedit/ regedt32 or other
registry too is the only way to modify a SAM database to reuse an old RID.
it requires a reboot of the NT box, and if you're ever thinking of
actually doing this, dear reader, then i think you're utterly stupid or
you're the kind of person i'd like to know, as you must REALLY know what
you're doing with NT :-) :-) ]

> I can't imagine *any* admin saying, "oh yes, that's just
> what we need - *ANOTHER* account database (which is what
> a mapping table is) to keep in sync with all the others 
> we have. Mmmm, yes. That'll make our jobs *much* easier..."
> 
> NOT !
> 
> :-).

tee hee :)