kdc: cross realm s4u2self handling

Isaac Boukris iboukris at gmail.com
Sat Sep 29 01:34:26 EDT 2018

On Fri, Sep 21, 2018 at 8:20 AM Isaac Boukris <iboukris at gmail.com> wrote:
> On Thu, Sep 20, 2018 at 4:03 AM, Greg Hudson <ghudson at mit.edu> wrote:
> > 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.
> I see, though I'm not sure I understand how this would happen.
> At any case, would it suffice to condition the check on:
> is_local_principal(kdc_active_realm, header_ticket->server)
> Or perhaps on (are those two necessarily equivalent here btw?):
> !is_cross_tgs_principal(header_ticket->server)

Also note, another assumption I made in Heimdal, was to skip the check
of 'ok_to_auth_as_delegate' before copying the forwardable flag when
issuing a referral.
For similar reasons; technically we don't have a DB entry to check,
and logically we are not issuing the service ticket but a referral so
let the final KDC do the check.
To my understanding, MIT code already has this assumption, see (which
suggests again that referrals are intended to work for s4u2self):

> >> 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].

This is now PR #852.
I got into some troubles when I tried to add unit-tests, first I
noticed that if a PAC is already signed, then the sign function would
just verify instead of re-signing, which would fail if it was signed
without realm and we want to sign it with realm.
It wasn't a problem in my tests with samba plugin, since the latter
always creates a new PAC and populates it anew, so I left that

Another issue was, enterprise principal with realm, as it got unparsed
to this when signing:
(gdb) p pac_princname
$25 = 0x60a8b0 "w2003final$\\@WIN2K3.THINKER.LOCAL at WIN2K3.THINKER.LOCAL"

So for this case I added KRB5_PRINCIPAL_UNPARSE_DISPLAY flag when
parsing the name to avoid the escaping.
I think we might want to add it generally (heimdal does it).

More information about the krbdev mailing list