I have the following setup:
Member in W4EDOM-L4.BASE
user in S2-W2012-L4.S1-W2012-L4.W2012R2-L4.BASE
The ticket for administrator@S2-W2012-L4.S1-W2012-L4.W2012R2-L4.BASE
arrives on the member with transited = S1-W2012-L4.W2012R2-L4.BASE,
which was added by the DC of W2012R2-L4.BASE.
The function krb5_check_transited() is called via gss_accept_sec_context()
and fails with KRB5KRB_AP_ERR_ILL_CR_TKT; Which causes krb5_decrypt_ticket()
to fail, in the log file it seems that the provided keytab didn't
have the correct key to decrypt.
The same problem happens with MIT Kerberos.
There were a discussion about this in August 2017:
Created attachment 15491 [details]
Work in progress for master
> I've used a modified Samba KDC (realm W4EDOM-L4.BASE) to generate
> tickets with invalid names (crealm: FAKEPRINC.PUBLIC)
> and tested the reaction of Windows KDC (realm: W2012R2-L4.BASE) when
> they received such a Ticket over a forest trust, where realm
> FAKRPRINC.PUBLIC is not configure as valid realm (upn-suffix) the for
> the trust boundary.
> krb5-without-pac-fake-realm-03.pcap.gz has no PAC in the ticket for
> TGS-REQ in frame 9. The crealm: FAKEPRINC.PUBLIC is rejected with
> ERR_POLICY in frame 10.
> krb5-with-pac-fake-realm-03.pcap.gz has a valid PAC (with the correct
> names and signatures) but an altered crealm. This is also rejected with
> So the policy check are not bound to the PAC, which means we can always
> use GSS_KRB5_CRED_NO_TRANSIT_CHECK_X if we're member of an active
> directory domain.
I'll also upload the captures and keytab here too...
Created attachment 15627 [details]
all.keytab (for krb5-without-pac-fake-realm-03.pcap.gz and krb5-with-pac-fake-realm-03.pcap.gz)
Created attachment 15628 [details]
Created attachment 15629 [details]