Cross realm S4U2Self cont.

Isaac Boukris iboukris at
Tue Aug 21 15:09:49 UTC 2018

On Mon, Aug 20, 2018 at 9:57 PM Isaac Boukris <iboukris at> wrote:
> First and most importantly, I believe I got the cross-realm s4u2self
> using enterprise name case - wrong.
> In my heimdal tests, I concluded that in this case windows would send
> the name only, like user at upnsuffix in PAC_CLIENT_INFO (without realm,
> same as none cross realm s4u2self with enterprise), and so have
> assumed that I can simply ignore this case (since the
> convert-to-enterprise should be no-op).
> However now, I clearly see that windows actually sends with realm,
> like user at upnsuffix@REALM.
> I can see how it worked for me despite my mistake in heimdal when I
> tested trust with windows while the service was on samba side, shortly
> because heimdal ignores the realm when comparing the names.
> But I'm unclear how the other way worked, when the service is on
> windows side - I'll have to test more thoroughly and to update the kdc
> commit in heimdal.

Actually, I was wrong and the heimdal changes are technically fine
(apart from the comments) for both enterprise and regular principal
(afaict now).
My error was to assume that if I unparse an enterprise principal and
then reparse it as enterprise then the two names would be identical.
However, in fact the enterprise name gets  unparsed to
"administrator\\ at SH5.COM" string and then when it is reparsed
as enterprise the whole three parts are saved in the name component,
$7 = (heim_general_string) 0x562a01a6efb0 "administrator at"
While the original enterprise name did not have the last part.

As a result of this mistake, the heimdal code works correctly for
enterprise name as it sends all three parts when the name was
originally an enterprise name, despite the fact that only meant it to
send two.
Anyway, I will refactor again the heimdal kdc commit and drop the
enterprise trick in favor of an explicit change to allow checking PAC
with the realm similar to the MIT poc in previous mail.

Sorry for the confusion, and thanks for reading for those who still are :)

More information about the samba-technical mailing list