Skip Menu |
 

Subject: S4U2Proxy and kvno error
Date: Mon, 1 Mar 2010 15:55:06 -0500
From: "Arlene Berry" <aberry@likewise.com>
To: <krb5-bugs@mit.edu>
Download (untitled) / with headers
text/plain 1.2KiB

I’m seeing some “Cannot find ticket for requested realm”  errors when using kvno with S4U2Proxy.  I tracked it down and the ultimate cause is that when krb5_server_decrypt_ticket_keytab() decrypts the encrypted part of the impersonated ticket it tries every keytab entry it finds with the right key type and the first one that works it uses.  It doesn't match the principal or the key version.  The problem occurs when krb5_server_decrypt_ticket_keytab() replaces the server principal in the ticket with the one in the keytab entry.  Since I'm using Active Directory for the KDC and have the account set up as a computer account, I have several variations on the principal name stored as separate keytab entries and the right one may not be the first keytab entry that can decrypt the ticket.  The result is that when kvno tries to use the impersonated credentials to get credentials for a service and krb5_get_credentials_for_proxy() looks for the proxy's TGT, it's looking for a TGT with the wrong principal name and ultimately returns KRB5_NO_TKT_IN_RLM.  I’m not sure what the right way to fix this is.  Is there a reason why krb5_server_decrypt_ticket_keytab() doesn't match the principal name?  Why does krb5_server_decrypt_ticket_keytab() replace the ticket's server principal?

The reason for not matching the name is to work with service aliases.
See http://k5wiki.kerberos.org/wiki/Projects/Aliases, specifically the
section "Server Principals". There was also some discussion of this on
krbdev in December 2008 starting here:

http://mailman.mit.edu/pipermail/krbdev/2008-December/007154.html

The change being discussed there was to krb5_rd_req, and the change to
krb5_server_decrypt_ticket_keytab didn't happen until it was necessary
in order to make S4U testing with kvno work. But the reasoning is the same.

I don't know the best resolution for your use case, because I'm not
familiar enough with AD to underestand why you'd have multiple entries
in a keytab for the same key with different names.
Date: Fri, 5 Mar 2010 15:42:03 -0500
From: "Arlene Berry" <aberry@likewise.com>
To: <krb5-bugs@mit.edu>
Subject: [krbdev.mit.edu #6673] S4U2Proxy and kvno error
RT-Send-Cc:
We've found it necessary to have 7 variations of the principal name as
Active Directory could issue a service ticket for any of them. If the
host's FQDN is comp1.domain.com, the sAMAccountName is COMP1$ and the
realm is REALM.COM, we store keytab entries for the following list of
principals for each supported encryption type:

COMP1$@REALM.COM
host/COMP1@REALM.COM
host/comp1@REALM.COM
host/comp1.domain.com@REALM.COM
host/COMP1.DOMAIN.COM@REALM.COM
host/COMP1.domain.com@REALM.COM
host/comp1.DOMAIN.COM@REALM.COM