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

Re: PAM, When?

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

i think you deleted a paragraph here...
> 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?

given that the NT domain structure is incontrol of the RID space, if you
were to use a simple mathematical function (for speed), then the NT domain
would consequently be indirectly in control of the UID space.

this is what happens on the NT posix subsystem.

to describe (again) this process, which is an existing example using a
mathematical function (monotonic):

user rid: add 0x10000 -> unix uid
group rid: add 0x20000 -> unix gid
trusted domain (first) user rid: add 0x30000 -> unix uid
trusted domain (second) add 0x40000

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

SAMBA is irrelevant, here.  Each and every NT workstation has its own SAM
database.  when you log in to either the domain named after the
"Workstation" in the  ctrl-alt-delete box or you have configured the NT
workstation to be in a workgroup not a domain, you are logging in to the
local SAM database.  the workstation is effectively a "PDC" for itself,
and cannot be a PDC for anything _other_ than itself.

what i propose is for linux boxes to do likewise.  this would mean being
able to select "local" login to the local workstation or to select
"domain" login to the PDC.

however, in the case where SAMBA is the PDC, yes: you could back-allocate
RIDs from the UNIX uids.

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

lettt mee thiiink....  yees, it would.  or, alternatively, you extend the
existing NT protocols (they are only DCE/RPC calls, after all) to include
an extra "info level" which returns not only the NT RIDs but also the UNIX
uid/gid pair.  this would only work on systems that were prepared to
support it (probably only non-microsoft systems).
> > 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,
> etc.
> Now, does *that* make sense?

yes it does :)

> The questions I'm asking try and cover three things:
>     1) My ignorance (a lot to cover)

sheesh, there aren't many people with heavily detailed knowledge of UNIX
authentication issues _and_ NT ones, and i certainly ain't one of them.

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

this can be done: it would also be good.

>     3) "Political" considerations (like the "bad guys" run the NT domain
>             structure, and they won't cooperate with me).

with enough thought, it should be possible to "stealth"-install linux
systems without the "bad guys" noticing.  i have heard people joking about
doing this with SAMBA instead of installing NT, and seeing if anyone


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