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