[PATCH] winbind interface to extract SIDs from PAC

simo idra at samba.org
Tue Jul 24 11:51:10 MDT 2012


On Tue, 2012-07-24 at 22:28 +1000, Andrew Bartlett wrote: 
> On Mon, 2012-07-23 at 19:52 -0400, simo wrote:
> > On Mon, 2012-07-23 at 16:07 -0600, Christof Schmitt wrote: 
> > > Andrew Bartlett <abartlet at samba.org> wrote on 07/20/2012 04:50:47 PM:
> > > 
> > > > On Thu, 2012-07-19 at 16:32 -0700, Christof Schmitt wrote:
> > > > > 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. 
> > > 
> > > Understood :) Here is the first version of the new interface. It
> > > extends the wbcAuthenticateUserEx call so that a client can provide a
> > > PAC. I extended the AUTH_CRAP call since the suggestion was to use the
> > > privileged pipe and AUTH_CRAP already uses this pipe. The usage from
> > > the client would like this:
> > > 
> > >         params.level = WBC_AUTH_USER_LEVEL_PAC;
> > >         params.password.pac.data = (uint8_t *)pac;
> > >         params.password.pac.length = length;
> > > 
> > >         wbc_err = wbcAuthenticateUserEx(&params, &info, &error);
> > > 
> > > If this is acceptable, i will look into the PAC signature verification
> > > next.
> > 
> > Andrew I would prefer a separate pipe, otherwise it is not easy to
> > distinguish between apache/squid/etc and a more trusted service.
> > Note that you do not necessarily have the keys to check the PAC in
> > winbind as a different service key may be used (I know not common in AD
> > but common in FreeIPA for example).
> 
> Simo,
> 
> Can you explain more how would winbindd fit in with FreeIPA in this
> situation? 

We use winbindd on the DC to contact trust domains. In this
configuration Winbindd only has the cifs/fqdn credentials and access to
the cross-realm password.
I was thinking it may be a good idea to allow for a more trusted
interface where validation is implied.

However you convinced me that for normal services the additional
validation, by default is valuable, I will add conditionals later if
needed.

Simo.

-- 
Simo Sorce
Samba Team GPL Compliance Officer <simo at samba.org>
Principal Software Engineer at Red Hat, Inc. <simo at redhat.com>



More information about the samba-technical mailing list