[PATCH] winbind interface to extract SIDs from PAC

[Andrew Bartlett]

On Fri, 2012-07-20 at 16:24 +0200, Andreas Schneider wrote:
> On Wednesday 18 July 2012 18:46:40 Andrew Bartlett wrote:
> > 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()?
> > 
> > > 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.
> > 
> > > 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've just looked at this code I don't think that LookupUserAliases gets what 
> you would like to see here. The domain LookupUserAliases is check is the local 
> domain not the domain winbind is joined to.

No, that's actually what I want, and it's those local domain (SAM)
groups that I'm discussing here. 

In any case, the point I've been arguing for is consistency - have this
call do the same thing as getusergroups() would do, by following as much
as possible the same steps, either by priming the info3/PAC cache, or by
using what the info3/PAC cache would have returned.

Thanks,

Andrew Bartlett

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