Hi,
thank you for looking into this issue.
From my point of view there are two main reasons to restore the documented ksu behaviour:
1) to not perform useless requests to TGS/DC, to spare resources; performing the TGS requests also raises the ksu execution latency..
2) from a security standpoint, to reduce the potential "attack surface"; this point is far more important to us, let me elaborate a bit:

A potential attacker may, in a limited time window, have the opportunity to stole the cached krb tickets. One TGT permits the attacker to impersonate the user for all resources/services in the domain; a service ticket (not forwardable) limits the attacker to impersonate the user only on the current host/service.

Taking this into account.. in order to use ksu.. we would like to populate the Krb cachefile only with the end-server service ticket (the cachefile should not contain a TGT).
At the moment we populate the cachefile in this way thanks to the kinit command with the -S option.
kinit permits to request an "initial" service ticket (In the future we will try to implement a way to populate a cache file with a service ticket acquired thanks to a TGT--stored in a different safe place--).
Security is a key point of our work, the documented ksu behaviour looked exactly what we need.
Regards
Fabiano

On 13 November 2017 at 23:21, Greg Hudson via RT <rt-comment@krbdev.mit.edu> wrote:

Thanks for the bug report, and apologies for not having time to look
into this last week.

It looks like ksu's behavior changed in release 1.13 as a result of
this pull request:

https://github.com/krb5/krb5/pull/170

although it may have been partially broken since referrals support
was introduced in release 1.6. Pull request 170 was motivated by a
bug caused by the referrals changes. At that time, we didn't realize
that the fix we arrived at (simplifying the ksu code) created a
mismatch with the documented behavior.

I can see several possible remedies here:

1. Change the documentation to match the code (talk only about using
a cached TGT).

2. Restore the documented behavior, but only make it work if the
canonicalized local hostname matches the host principal in the ccache
service ticket and the system keytab.

3. Restore the documented behavior, and make it work for any host
principal in the system keytab.

The serverfault post contains a lot of detail about the test case,
but doesn't explain why the documented behavior is important in this
use case. Is there a reason why it's not sufficient for ksu to look
for a TGT in the ccache and make a TGS request to verify it?