New group mapping and the auth subsystem

[Andrew Bartlett]

Jeremy Allison wrote:
> 
> On Sun, Dec 02, 2001 at 11:34:58AM +1100, Andrew Bartlett wrote:
> 
> > Ok, I'm not worried about the actual token - and I understand now that
> > this is indeed machine-specific, but I am worried about the NT groups
> > that make up that token, and I want to ensure that we don't waste the
> > information we get when doing this.
> 
> So long as we save the groups list on doing a netlogon, or get
> the groups list from the PAC, we're ok here (not losing info).

Good, that was how I was thinking.
 
> > The only stuff I've found at all refers to the lsalogonuser call, which
> > in fact retuns a token.  (This is on each machine of course).  What I'm
> > looking at is where the lsa gets the info for that token.
> 
> >From the netlogon (or kinit). That's what lsalogon user is doing under
> the covers.

Thats what I thought.

> > > you're mixing authentication and autorisation. The authentication backend
> > > has nothing to do with generating an autorisation token ! I'm working on
> > > the TOKEN stuff right now.
> >
> > Correct, but it is intimatly involved in creating a list of member
> > groups - as it is the only subsystem with direct (no extra network
> > traffic) access to that information.
> 
> > But how do you (on a member server) get the list of sids that a user
> > has?  In particular, how do we do this if we don't have winbind?
> 
> You can't get the list of SIDs for an "arbitrary" user, they
> need to have logged on via netlogon or PAC. Then we know what
> SIDs they have (from the return value) and we store it in the
> token.

OK, so what I'm trying to do is get the interface the same no matter if
we got that list of SIDs from the netlogon, the PAC or if we got them by
mapping local unix groups.  

That way we always deal with this list of groups in the same way.  In
particualr, for the trusted domains case, we will take in a list of NT
groups and need to push them back out again - while the same codepaths
need to also take into account the case when we are the PDC.  Similarly
for the session setup case.

So I hope its now becoming a bit clearer what I'm proposing, but code
speaks much loader than words and I'll just look at how to rework it
once it hits the tree if need be.

> I understand where JF is coming from....
> 
> Jeremy.

-- 
Andrew Bartlett                                 abartlet at pcug.org.au
Manager, Authentication Subsystems, Samba Team  abartlet at samba.org
Student Network Administrator, Hawker College   abartlet at hawkerc.net
http://samba.org     http://build.samba.org     http://hawkerc.net