kdc: cross realm s4u2self handling
Greg Hudson
ghudson at mit.edu
Wed Sep 19 18:33:25 EDT 2018
On 09/19/2018 07:08 AM, Isaac Boukris wrote:
> > I may have unwittingly been preserving a bug rather than an intentional
> > restriction, so we can probably relax it.
> Ok, it makes sense now, I can see it'd have failed the comparison in
> kdc_process_s4u2self_req() (thanks for the detailed clarification).
It occurs to me that a within-realm S4U2Self request (i.e. one using a
local TGT header ticket rather than a cross-TGT one) should still fail
if it results in a referral. I will try to put together a test case for
that.
> Note that in my heimdal work, I have assumed that we can skip this
> comparison check when the service isn't local since we are not issuing a
> ticket to self but a referral, so let the KDC of the service do the
> check when it issues the service ticket.
> The reason it came up was, because heimdal has a more relaxed check
> implemented via hdb plugin which allows matching different names, like
> an SPN to a regular principal name, by looking up both name in db and
> calling the plugin callback with both entries, then samba plugin just
> compares the SID to confirm it's the same principal.
> However, when the service is not local, we don't have these db handles
> so we can't do that.
Maybe. I can't find a flaw in your logic--in the cross-realm case, we
aren't issuing a ticket for the requested service name and we don't have
a DB entry for it, so surely it can't matter too much what it was.
> I guess my main question is whether we need to verify this PAC at, or we
> can just discard it, which is more of a Windows question.
I can't think of a reason to verify the PAC in the TGT unless the KDC is
going to use its contents.
> Other than that, what do you think of the pac_verify/sign_ex() routines,
> does it look ok?
I looked over them briefly and don't have a problem with them. If you
submit a PR I will examine them more closely and cross-check against
[MS-PAC] and [MS-SFU].
More information about the krbdev
mailing list