[PATCH] winbind interface to extract SIDs from PAC

Andrew Bartlett abartlet at samba.org
Wed Jul 18 19:14:38 MDT 2012


On Wed, 2012-07-18 at 17:14 -0400, simo wrote:
> On Wed, 2012-07-18 at 22:08 +0200, Volker Lendecke wrote: 
> > On Wed, Jul 18, 2012 at 09:47:51AM -0700, Christof Schmitt wrote:
> > > 1) Ganesha passes the PAC to wbcAuthenticateUserEx and retrieves
> > >  the user name and the domain.
> > 
> > Question -- does the PAC contain enough information to make
> > sure it is authentic? Does it contain a checksum signed with
> > the workstation password? Or do we have to pass on the whole
> > ticket including all the krb5 wrapping and encryption?
> 
> You need the pac blob, it contains the server and the kdc signatures.
> The logon_info is one of the buffers signed by those.
> 
> The problem is that you need to fully trust the service that receives
> the PAC if it has access to the keytab, because possession of the long
> term secret means you can fake-sign a PAC. However if you are willing to
> waste time with RPC calls you can also ask the KDC to check its
> signature is real. It's a b it of waste though to have to contact the
> KDC. It would be better to not give long term keys to services at all so
> you do not have to.

I've been thinking this over a little more since my last mail:

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.

Andrew Bartlett

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



More information about the samba-technical mailing list