GSSAPI s4u2proxy with client keytab initiation and Heimdal KDC

[Alan Braggins]

On 05/12/13 17:29, Greg Hudson wrote:
> On 12/05/2013 07:33 AM, Alan Braggins wrote:
>> I'm trying to use Constrained Delegation in GSS-API, and seem to have
>> hit the same "KDC has no support for padata type" problem described here:
>> https://groups.google.com/forum/#!msg/comp.protocols.kerberos/SrNyMS9Arfo/7sMq5ygMqcEJ
>>
>> I'm hoping someone has advice on fixing or working around it.
>
> I've figured out what the bug is here (the FAST TGS encoding is
> disguising the S4U2Self padata when interpreted by a non-FAST-aware
> KDC), and am consulting with the developer of FAST TGS support on how
> best to fix it.
>
> I have attached a small patch to disable FAST TGS client support which
> you can use as a temporary workaround.

Thanks. I'll try the github fix too.


>> (On the subject of keytab initiation, it feels odd that I'm using
>> krb5_gss_register_acceptor_identity to point to the same keytab as
>> KRB5_CLIENT_KTNAME, because s4u2self needs GSS_C_BOTH. Am I missing
>> something? Is there an API equivalent of
>> krb5_gss_register_acceptor_identity, or only the environment variable?)
>
> gss_acquire_cred_from() will let you specify the client and acceptor
> keytab, allowing you to get rid of both
> krb5_gss_register_acceptor_identity and the KRB5_CLIENT_KTNAME setting.

Thanks again.


>> And a followup question on client keytab initiation - it appears that
>> if I have no cached credential, then it works. But if I have a cached
>> credential that has expired, then gss_acquire_cred is returning me an
>> expired credential, not renewing it.
>
> Was the cached credential created with client keytab initiation, or by
> hand?  I think the refresh machinery only works in the former case,
> although we could perhaps make it smarter.

I was fairly sure I'd seen it in the former case too, but maybe I'm
misinterpreting. I'll do some more testing.