New group mapping and the auth subsystem

[Andrew Bartlett]

Jean Francois Micouleau wrote:
> 
> On Sun, 2 Dec 2001, Andrew Bartlett wrote:
> 
> > Yes, I'm interested in the account policy stuff, and I'll look into
> > adding that kind of thing to the sam_account_ok checks, but I think you
> > miss my point.
> 
> ok.
> 
> > If I want to conduct a privileged action on the server (like adding a
> > machine account, changing a share's properties), when (and how) will it
> > be checked that I have the privileged to conduct this operation?
> 
> in the rpc lsa|samr|spoolss open call first to check against the desired
> access.
> 
> and next in each rpc call.
> 
> > And when is the privileges list for this check calculated?  (The
> > NT_USER_TOKEN).
> >
> > This token needs to be generated at some point.
> 
> The NT_USER_TOKEN is already generated. I talk to jeremy 2 days ago and he
> agreed with some changes I want to make to it.

What I'm interested in is what this token is generated from.  In
particular, its primary input is a list of SIDs, mostly representing the
user's groups.

This list of groups needs to be arrived at somewhere.  Under NT, this
list of groups is supplied either locally (on the PDC) or as part of the
authentication reply.  In particular, we know that we must use the list
of groups in the info3 returned from the domain logon request before an
NT_USER_TOKEN can be complete.  I understand that the PAC contains
similar data - the idea being to avoid unnecessary calls to the DC to
obtain group information.

> > Furthermore, this token (or its constituent parts) is not always
> > generated by the group mapping code, but can be generated by the PDC,
> > and passed to a domain member by means of a PAC or an info3 in a
> > samlogon reply.
> 
> wrong. A token is valid only on the machine it has been generated.
> As are the privileges valid only on the machines they are defined.

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.
 
> check MSDN, it's documented.

Any references?  MSDN is being particularly unhelpful to me :-(

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.
 
> > This token needs to be carried from the authentication backend (where we
> > get it, by hook or by crook) into the rest of samba where it can be
> > associated with a user when they request these actions.
> 
> 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.

> > The reason I want to do it like this is because if follows the model NT
> > uses very closely, and it makes maximum use of the available
> > information.  Much of my work in the auth subsystem has been aimed at
> > simply *not* throwing away information if we can avoid it.
> >
> > In any case, how did you propose obtaining this privilege information
> > from the DC (given samba as a member server)?
> 
> you can't get them from DCs. They are local.
> 
>         J.F.

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?

This will almost certainly be much clearer with code on the table.

Thanks for all the hard work!

Andrew Bartlett

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