[PATCH] winbind interface to extract SIDs from PAC

Christof Schmitt christof.schmitt at us.ibm.com
Thu Jul 19 17:32:15 MDT 2012

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?

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

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?


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

More information about the samba-technical mailing list