[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: PAM, When?

Luke Kenneth Casson Leighton wrote:

> [sorry about this: does anyone object to this discussion taking place on
> this list?]
> On Tue, 27 Oct 1998 alanr@bell-labs.com wrote:
> > Luke Kenneth Casson Leighton wrote:
> >
> > > On Tue, 27 Oct 1998 alanr@bell-labs.com wrote:
> > >
> > > > Aren't NT RIDs assigned by the system, with no choice as to how they are
> > > > assigned?
> > >
> > > correct.  in this instance, i am _talking_ about the system.
> >
> > I understand.  However, it is also very important to have the ability to
> > plug-and-play with what Microsoft does to you.  Also, if you have an
> > pre-existing domain structure, changing RIDs for everyone is a
> > REALLY BIG DEAL, involving touching nearly every file in the domain structure.
> to explain: using an existing SAM database (on an existing PDC, whether it
> be Advanced Server for UNIX; NT 3.1, 3.5, 3.51 or 4.0; Samba-2.0.0alpha
> etc)
> in this instance, i propose that the linux box contact the PDC, obtain the
> Domain SID (typically S-1-5-21-xxx-yyy-zzz) plus the user's RID: if an
> internal-uid-lookup fails, an internal-uid is generated and associated
> permanently in a database with the SID+RID.

And this case assumes that the NT domain structure is completely in control of the
UID name space?  How are trust relationships handled in this situation?

> if no PDC exists, then the linux box will have to be the PDC for itself
> (which is _exactly_ how NT workstation operates, in case anyone is
> wondering!) and only allow local logins to itself.
> in this instance, again the linux box obtains a SID (for itself, just as
> NT workstation does) plus the user's RID, except that there is more
> flexibility here: the RID can be generated such that it maps easily to a
> UNIX uid: e.g a pre-existing one).

I assume this paragraph only applies if SAMBA is "in control" of domain RIDs (and
UNIX ids too?).  Again, the question about trust relationships.

> so assuming a fixed, simple and fast mathematical relationship between
> RIDs and uids, in the first case the RIDs are what dictates what the uids
> are; in the second case the uids can dictate what the RIDs are.
> in either case, however, a second lookup table could conceivably be added
> which maps SID+rid to external UNIX uid, as well as and independent from
> the kernel-based internal-uid.

So, this lookup table is "global" in some sense?  That is, it has to be of at least
the same scope as the NIS domains or whatever.  If the NIS domain is company-wide,
then this database has to also be company-wide (?).

> does that make sense?

I think so.  Let's see.   For the "second lookup table", you need to separate the
manually mapped UID/GID "namespaces" from the automatically-generated RID->UID
mapped "namespace".  And people with a "legacy" UNIX account could continue
(through the manually-generated mappings) to access their files in some reasonably
sane fashion.  Perhaps you could reserve the top byte of the UNIX id to represent
this kind of info:  0 == "native" UNIX id, 1 == NT domain #1, 2 == NT domain #2,
Now, does *that* make sense?

The questions I'm asking try and cover three things:
    1) My ignorance (a lot to cover)
    2) "legacy" considerations (like I already have a UNIX or NT id)
           (with considerations to allow eventually phasing this out
                and eliminating the second mapping table).
    3) "Political" considerations (like the "bad guys" run the NT domain
            structure, and they won't cooperate with me).

The real world is very much full of #2 and #3.  #1 may be impossible :-)


        -- Alan Robertson

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index] []