[PATCH] winbind interface to extract SIDs from PAC

[Andrew Bartlett]

On Wed, 2012-07-18 at 09:47 -0700, Christof Schmitt wrote:
> Andrew Bartlett <abartlet at samba.org> wrote on 07/18/2012 01:46:40 AM:
> 
> > On Tue, 2012-07-17 at 11:06 -0700, Christof Schmitt wrote:
> > 
> > > I looked at earlier notes about the discussion we had with
> > > Ganesha developers. Their problem is that the principal in the
> > > kerberos ticket does not contain the domain information. For
> > > multi-domain environments Ganesha needs the user and group data
> > > from the PAC since that already includes the domain information.
> > 
> > How does Ganesha get the user's groups at the moment?  I presume it
> > calls initgroups or getgrouplist()?
> 
> Yes. After going through the code, it seems that Ganesha calls
> nfs4_gss_princ_to_ids in libnfsidmap and this library calls
> getgrouplist.
> 
> > > The original idea was to provide a winbind API call that
> > > translates the user and groups in the PACs to the mapped unix
> > > ids. While implementing this, i ended up calling sids_to_xids
> > > internally in winbind, and moving that call out to the client
> > > seemed like a simpler solution.
> > > 
> > > I think there is value in providing also the expanded SIDs or the
> > > corresponding unix ids. The Ganesha developers might not be aware
> > > of this behavior. 
> > 
> > This is what I've been trying to get at.  Indeed, up until now they and
> > you haven't had to know that a call to initgroups() returns these groups
> > as well.  In short, it 'just works', which is is a good property of an
> > NSS interface. (See winbindd_getgroups.c and wb_gettoken.c for how this
> > is handled). 
> > 
> > Of course it doesn't 'just work' for users from a foreign domain were
> > winbindd has not seen the PAC, which is where we get to your desired
> > extension.
> 
> And i assume that the same also applies when there is only one
> domain for users that access NFS, but not Samba. In this case
> Ganesha would retrive the Kerberos ticket with the PAC and
> winbind does not know about this.

If we don't know about the user at all, then we will try and work it out
from the DC.  This is reasonably reliable on our local domain - but if
we have stale information about a user, we may choose that over a
runtime lookup.  Also, runtime lookups involve the very DC communication
that the PAC was designed to avoid!

Anyway, this is just another reason why doing this work, and doing it
right is a good thing, and I'm glad we are homing in on solutions here
(even if not as simple as first imagined). 

> > > I would suggest to include a winbind call now
> > > to get the user ids from the PAC. Ideally this call can be
> > > extended in the future when the infrastructure to get the
> > > expanded ids is available. At the same time we can talk to the
> > > Ganesha developers if they would also need the expanded list of
> > > ids.
> > 
> > In the further investigation, if Ganesha uses initgroups() or
> > getgrouplist() at the moment, then there is no reasonable choice but to
> > do this properly (expand the local aliases) now, as to do otherwise
> > would risk a regression (the answer won't be the same).
> > 
> > In short, what I suggest Ganesha needs is a call like getgrouplist(),
> > but that takes a PAC as the first argument.  Then the output can be
> > treated in the same way, but the results will be more complete, because
> > the PAC will have been consulted.
> > 
> > The implementation will be quite similar to wb_gettoken() (it could be
> > an optional behaviour of that call), except it would skip
> > LookupUserGroups and only call LookupUserAliases.
> > 
> > I hope this clarifies my concerns, and explains why I think simple PAC
> > parsing isn't enough for this interface. 
> 
> There are two issues to solve: Ganesha receives a Kerberos ticket
> with a PAC. First, it has to find the uid and primary gid. In
> case there are multiple domains the information which is the
> correct user name to get the mapping for (domain1\user or
> domain2\user) is only in the PAC.
> 
> And second, Ganesha needs the list of groups as we are discussing
> now.
> 
> I am trying to find out how to proceed now. Volker and Simo seem
> to prefer an interface to pass the PAC to winbindd and then call
> getgrouplist to get the groups through the NSS interface. I will
> look into Volker's suggestion to extend
> wbcAuthenticateUserEx. The call sequence would then look like
> this:
> 
> 1) Ganesha passes the PAC to wbcAuthenticateUserEx and retrieves
>  the user name and the domain.
> 2) The information from this call can be used to get the uid and
>  gid for the primary group.
> 3) The complete list of groups for the user can be obtained
>  through getgrouplist.
> 
> Does this sound like a good approach?

As the other replies discuss, the issue is the verification.  There are
three ways to approach this:
 - supply the PAC via a totally trusted mechanism (we probably want a
level of protection greater than the privileged pipe, which is typically
shared with apache and squid)
 - supply the whole signed ticket, and totally trust anyone who has
access to the Samba machine account (that winbindd will then decrypt the
ticket with).
 - something based on gss-proxy (I've not yet looked into simo's work
here) or passing the whole and only GSSAPI exchange to winbindd (then
returning the lucid security context details for crypto).

While the second approach will work in most cases (and we rely on it in
dlz_bind9), there are still problems.  The incoming ticket is part of an
SPNEGO exchange, and what we are doing will essentially be a replay of
first packet of that exchange.  We have to hope that the exchange
completes in one round-trip, discard the reply and then extract the
PAC.  

I hope this clarifies things,

Andrew Bartlett
-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org