[cifs-protocol] KERB-ERROR-DATA code 136

[Julien Rische]

Hello team,

We are experiencing Active Directory interoperability issues for the MIT
Kerberos 1.20 release, which is introducing generation of PAC for all tickets
by default. There are two scenarios:

* Cross-realm AD TGS request from an MIT Kerberos client (realm trust)[1]
* Cross-realm S4U2Self request for a FreeIPA service to impersonate an AD user
  (forest trust)[2]

In both cases, a TGS-REQ[3][4] against AD using the cross-realm TGT results in
a generic error (MS-SFU 4.2 step 3[5] in S4U2Self case). We suspect these two
failures may have the same underlying cause, because of the "e-data" attribute
from the KRB_ERR_GENERIC message[6][7]:

SEQUENCE {
  SEQUENCE {
    [1] {
      INTEGER 136
      }
    [2] {
      OCTET STRING
        ...
      }
    }
  }

The octet string is different, but the integer is the same in both scenarios.
According to the MS-KILE specification, this piece of data should be a
KERB-ERROR-DATA structure[8]. However the 136 integer do not match any of the
documented "data-type" values.

This error is most likely related to the PAC, because in the realm trust case,
the cross-realm TGS-REQ works in case PAC support is disable on the MIT KDC
(i.e. the MIT TGT does not contain a PAC).

Could you please give us more details about KERB-ERROR-DATA code 136, and check
if you see anything wrong in the PACs that are being used in these 2 scenarios?

--
Julien Rische
Software Engineer
Red Hat


[1] krb5_1_20_mit_ad_realm_trust.(pcap|keytab) files in attachment
[2] krb5_1_20_ipa_ad_trust_s4u2self.(pcapng|keytab) files in attachment
[3] krb5_1_20_mit_ad_realm_trust.pcap packet no. 7
[4] krb5_1_20_ipa_ad_trust_s4u2self.pcapng packet no. 11
[5] https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-sfu/f35b6902-6f5e-4cd0-be64-c50bbaaf54a5
[6] e-data in krb5_1_20_mit_ad_realm_trust.pcap packet no. 8 or
krb5_1_20_mit_ad_realm_trust_edata.blob in attachment
[7] e-data in krb5_1_20_ipa_ad_trust_s4u2self.pcapng packet no. 12 or
krb5_1_20_ipa_ad_trust_s4u2self_edata.blob in attachment
[8] https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-kile/25fabd02-560d-4c1f-8f42-b32e9d97996a
-------------- next part --------------
A non-text attachment was scrubbed...
Name: krb5_1_20_mit_ad_realm_trust.keytab
Type: application/octet-stream
Size: 1962 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/cifs-protocol/attachments/20220912/91c1b755/krb5_1_20_mit_ad_realm_trust.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: krb5_1_20_mit_ad_realm_trust_edata.blob
Type: application/octet-stream
Size: 244 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/cifs-protocol/attachments/20220912/91c1b755/krb5_1_20_mit_ad_realm_trust_edata.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: krb5_1_20_ipa_ad_trust_s4u2self_edata.blob
Type: application/octet-stream
Size: 247 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/cifs-protocol/attachments/20220912/91c1b755/krb5_1_20_ipa_ad_trust_s4u2self_edata.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: krb5_1_20_mit_ad_realm_trust.pcap
Type: application/vnd.tcpdump.pcap
Size: 7685 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/cifs-protocol/attachments/20220912/91c1b755/krb5_1_20_mit_ad_realm_trust.pcap>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: krb5_1_20_ipa_ad_trust_s4u2self.keytab
Type: application/octet-stream
Size: 2437 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/cifs-protocol/attachments/20220912/91c1b755/krb5_1_20_ipa_ad_trust_s4u2self.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: krb5_1_20_ipa_ad_trust_s4u2self.pcapng
Type: application/x-pcapng
Size: 11912 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/cifs-protocol/attachments/20220912/91c1b755/krb5_1_20_ipa_ad_trust_s4u2self.bin>