[krbdev.mit.edu #5954] ksu fails without domain_realm mapping for local host

[Public Submitter via RT]

Here is a trace from a ksu built with debugging support:

wanderer:~> ./ksu -D
GET_best_princ_for_target: via prompt passwd list choice: approximation
of princ in trials # 0 
GET_best_princ_for_target result-best principal rra/root at stanford.edu 
 source cache =  FILE:/tmp/krb5cc_1000
 target cache =  FILE:/tmp/krb5cc_0.1
krb5_check_exp: the krb5_clockskew is 300 
krb5_check_exp: currenttime - endtime -82497 
krb5_check_exp: the krb5_clockskew is 300 
krb5_check_exp: currenttime - endtime -82497 
krb5_check_exp: the krb5_clockskew is 300 
krb5_check_exp: currenttime - endtime -82497 
 krb5_auth_check: Client principal name: rra/root at stanford.edu
 krb5_auth_check: Server principal name: host/wanderer.stanford.edu@
ksu: Matching credential not found While Retrieving credentials
 local tgt principal name: krbtgt/stanford.edu at stanford.edu
WARNING: Your password may be exposed if you enter it here and are logged 
         in remotely using an unsecure (non-encrypted) channel. 
Kerberos password for rra/root at stanford.edu: : 
krb5_auth_check: got ticket for end server 
 out_creds->server: host/wanderer.stanford.edu@
krb5_verify_tkt_def: verifying target server
 server: host/wanderer.stanford.edu@
 tkt->server: host/wanderer.stanford.edu at stanford.edu
ksu: Wrong principal in request while verifying ticket for server
Authentication failed.

The problem appears to stem from the fact that ksu rolls its own ticket
verification and doesn't use krb5_verify_init_creds.  Is there some
reason why it doesn't do this, or does it just predate that API?  If it
just predates the API, I might be able to take a shot at producing a patch.