[PATCH] winbind interface to extract SIDs from PAC

[Andrew Bartlett]

On Thu, 2012-07-19 at 16:32 -0700, Christof Schmitt wrote:
> Andrew Bartlett <abartlet at samba.org> wrote on 07/18/2012 06:14:38 PM:
> 
> > If the service has the same keytab keys as winbindd, then it is safe to
> > say that they are in the same security context.  In that case, accepting
> > such a PAC over wbcAuthenticateUserEx using the privileged pipe and
> > verifying that by accepting a PAC signed with the keys winbind holds
> > seems reasonable.
> > 
> > The main challenges with this can be worked around, but are essentially:
> >  - the PAC doesn't tell you which principal, kvno and key was used (the
> > GSSAPI libs know, because it is the service key used to decrypt the
> > ticket, but an outside caller would probably fall back to trial and
> > error.
> >  - the PAC signature type is not a one-to-one mapping to a key type (it
> > can be a hmac checksum over a DES key).
> > 
> > These are not insurmountable challenges, just fiddly.
> 
> How would you suggest to approach this? Just pass the PAC over
> wbcAuthenticateUserEx and find the right key inside winbind? Or add
> some additional information to wbcAuthenticateUserEx to avoid guessing
> inside of winbindd?

The problem is that we don't get that information outside of GSSAPI, so
guessing it seems like the only option. 

> I am also looking where to start implementing this. Is there a list of
> known keys available in winbind that can be tried for the PAC
> verification?

The gse_krb5 code in source3/librpc/crypto creates a set of possible
keys to hand to GSSAPI from the secrets.tdb or keytab.  It will be one
of those. 

> Another thought would be that the PAC verification is only required
> for adding the PAC data to the netsamlogon cache. Without this step,
> winbindd would contact the DC on the getgrouplist call. The info3 data
> returned from wbcAuthenticateUserEx would already help with the
> Ganesha authentication requirements. Would it make sense to first
> implement the PAC interface for wbcAuthenticateUserEx and add the PAC
> verification and cache priming later? Or am i missing something here
> and this does not work?

That gets us back to where we started, unless the wbcAuthenticateUserEx
call is extended to do the token expansion (perhaps as an extra flag for
both NTLM and PAC use cases).  This wouldn't be too hard to do however. 

Simo's point about it being better to prime the cache and use the
original API calls would still stand however. 

Andrew Bartlett

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