[PATCH] winbind interface to extract SIDs from PAC

[Christof Schmitt]

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.

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

Regards,

Christof Schmitt || IBM || SONAS System Development || Tucson, AZ
christof.schmitt at us.ibm.com  ||  +1-520-799-2469  (T/L: 321-2469)