Subject: | pkinit-obtained tickets can't make TGS requests |
In krb5 1.7, pkinit AS requests work and you get initial tickets.
However, if you try to make a TGS request with those tickets, it doesn't
work. The failure is as follows:
* process_tgs_req calls kdc_process_tgs_req.
* kdc_process_tgs_req calls krb5int_find_authdata to see if the ticket
should be refused on account of containing FX_ARMOR authdata.
* krb5int_find_authdata calls find_authdata_1.
* find_authdata_1 runs into an AD_IF_RELEVANT container and attempts to
decode it. This decode operation fails.
* find_authdata_1 continues its loop, but never performs another
operation which would change retval from its current failure value.
* The failure propagates up to process_tgs_req, which sets status to
"PROCESS_TGS" and returns an error reply.
The behavior of find_authdata_1 is a bit dodgy, but the real issue is of
course why the decoding of the AD_IF_RELEVANT container fails.
However, if you try to make a TGS request with those tickets, it doesn't
work. The failure is as follows:
* process_tgs_req calls kdc_process_tgs_req.
* kdc_process_tgs_req calls krb5int_find_authdata to see if the ticket
should be refused on account of containing FX_ARMOR authdata.
* krb5int_find_authdata calls find_authdata_1.
* find_authdata_1 runs into an AD_IF_RELEVANT container and attempts to
decode it. This decode operation fails.
* find_authdata_1 continues its loop, but never performs another
operation which would change retval from its current failure value.
* The failure propagates up to process_tgs_req, which sets status to
"PROCESS_TGS" and returns an error reply.
The behavior of find_authdata_1 is a bit dodgy, but the real issue is of
course why the decoding of the AD_IF_RELEVANT container fails.