Bug 2060421
| Summary: | Invalid KDC signature encryption type for PAC [rhel-9] | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 9 | Reporter: | Alexander Bokovoy <abokovoy> | ||||||
| Component: | krb5 | Assignee: | Julien Rische <jrische> | ||||||
| Status: | CLOSED ERRATA | QA Contact: | Ganna Kaihorodova <gkaihoro> | ||||||
| Severity: | unspecified | Docs Contact: | lmcgarry | ||||||
| Priority: | unspecified | ||||||||
| Version: | 9.0 | CC: | aperotti, fhanzelk, gfialova, gkaihoro, jrische, lmcgarry, sumenon | ||||||
| Target Milestone: | rc | Keywords: | Triaged | ||||||
| Target Release: | --- | ||||||||
| Hardware: | Unspecified | ||||||||
| OS: | Unspecified | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | krb5-1.21.1-1.el9 | Doc Type: | Enhancement | ||||||
| Doc Text: |
.IdM supports the option to control the encryption type used to sign the PAC
By default, the Kerberos Key Distribution Center (KDC) generates an AES HMAC-SHA2 signature for the Privilege Attribute Certificate (PAC). However, this encryption type is not supported by Active Directory (AD). As a result, AD cross-realm constrained delegation requests are not processed correctly.
With this enhancement, you can now control the encryption type used to sign the PAC by setting the `pac_privsvr_entype` attribute on the TGS principal, `krbtgt/[realm]@[realm]`, to the required encryption type for the target realm. In IdM, this string attribute is automatically configured when an AD trust exists.
----
WARNING: This update is about standalone MIT realms. Do not change the Kerberos Distribution Center (KDC) configuration in RHEL Identity Management.
----
For example, for an `MIT` realm and an `AD` realm, to ensure cross-realm ticket-granting tickets (TGT) use AD-compatible encryption types, an administrator must configure the cross-realm TGS principal as shown below on the MIT side. This results in cross-realm TGTs using the AES 256 HMAC-SHA1 encryption type and constrained delegation requests being processed correctly.
----
kadmin.local <<EOF
setstr krbtgt/AD@IPA pac_privsvr_enctype aes256-cts-hmac-sha1-96
setstr krbtgt/IPA@AD pac_privsvr_enctype aes256-cts-hmac-sha1-96
EOF
----
|
Story Points: | --- | ||||||
| Clone Of: | |||||||||
| : | 2125182 2209621 (view as bug list) | Environment: | |||||||
| Last Closed: | 2023-11-07 08:56:13 UTC | Type: | Bug | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Bug Depends On: | 2016312, 2027125, 2124463 | ||||||||
| Bug Blocks: | 2209621 | ||||||||
| Deadline: | 2023-06-05 | ||||||||
| Attachments: |
|
||||||||
This is for two-way trust between IPA and Active Directory. Reproduction steps: 1. Install RHEL in FIPS mode 2. Run 'update-crypto-policies --set FIPS:AD-SUPPORT' 3. Install RHEL IdM in FIPS mode and enable for trust (ipa-server-install --setup-adtrust --setup-dns ...) 4. Establish trust with AD (ipa trust-add ad.domain --two-way=true) 5. Try to acquire a ticket to a service on AD side like in the description. According to the Windows documentation[1], the root cause of KRB_ERR_GENERIC (0x3C) can be one of the following ones: * Group membership has overloaded the PAC. * Multiple recent password changes have not propagated. * Crypto subsystem error caused by running out of memory. * SPN too long. * SPN has too many parts. I guess here, it's probably a cryptographic error. I still have to figure out how I can get this kind of logs on Windows Server. [1] https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4769 Cross-realm IPA/AD TGS and S4U2Self requests are failing because the PAC "KDC (privilege server)" checksum (which is in fact a signature) generated by MIT krb5 is using the strongest encryption type permitted by the Kerberos configuration. In IPA's case, since support for RFC8009[1]'s encryption types was added[2], this encryption type is AES256-CTS-HMAC-SHA384-192.
However, the only supported encryption types allowed for this purpose by MS-PAC[3] are:
* RC4-HMAC (which is no longer allowed by RHEL MIT krb5)
* AES128-CTS-HMAC-SHA1-96
* AES256-CTS-HMAC-SHA1-96
As a consequence, AD rejects the PACs generated by IPA since they contain unsupported checksum types. A way to filter encryption types used for PAC signatures has to be added to MIT krb5. This is being discussed upstream[4].
Kerberos
Record Mark: 2605 bytes
tgs-req
pvno: 5
msg-type: krb-tgs-req (12)
padata: 4 items
PA-DATA pA-TGS-REQ
padata-type: pA-TGS-REQ (1)
padata-value: 6e8206ab308206a7a003020105a10302010ea20703050000000000a38205bc618205b830…
ap-req
pvno: 5
msg-type: krb-ap-req (14)
Padding: 0
ap-options: 00000000
ticket
tkt-vno: 5
realm: TESTREALM.TEST
sname
enc-part
etype: eTYPE-AES256-CTS-HMAC-SHA1-96 (18)
kvno: 1
cipher: 7dffe293c57e857d0467a517d247a0380bfddc9e3b102bd2607da2d7e704b91ecdc8e675…
Decrypted keytype 18 usage 2 using keytab principal krbtgt/AD-5NXB.TEST (id=keytab.79 same=0) (422399f7...)
encTicketPart
Padding: 0
flags: 40290000
key
crealm: TESTREALM.TEST
cname
transited
authtime: 2022-09-21 13:29:22 (UTC)
endtime: 2022-09-22 13:04:45 (UTC)
authorization-data: 2 items
AuthorizationData item
ad-type: aD-IF-RELEVANT (1)
ad-data: 308203fa308203f6a00402020080a18203ec048203e80700000000000000010000000002…
AuthorizationData item
ad-type: aD-WIN2K-PAC (128)
ad-data: 0700000000000000010000000002000078000000000000000c000000d600000078020000…
Verified Server checksum 16 keytype 18 using keytab principal krbtgt/AD-5NXB.TEST (id=keytab.79 same=0) (422399f7...)
Verified KDC checksum 20 keytype 20 using keytab principal krbtgt/TESTREALM.TEST (id=keytab.6 same=0) (ed71e537...)
Num Entries: 7
Version: 0
Type: Logon Info (1)
Type: UPN DNS Info (12)
Type: Unknown (17)
Type: Unknown (18)
Type: Client Info Type (10)
Type: Server Checksum (6)
Type: Privsvr Checksum (7)
Size: 28
Offset: 968
PAC_PRIVSVR_CHECKSUM: 14000000023601ab62a5ea65a8221c6683a38000eab07a107d34d385
Type: 20
Signature: 023601ab62a5ea65a8221c6683a38000eab07a107d34d385
[1] https://datatracker.ietf.org/doc/html/rfc8009
[2] https://pagure.io/freeipa/c/09d5b938c128d8bb01ae40b5d736a266c6075b39
[3] https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-pac/3122bf00-ea87-4c3f-92a0-91c0a99f5eec
[4] https://github.com/krb5/krb5/pull/1268
(In reply to Julien Rische from comment #27) > Cross-realm IPA/AD TGS and S4U2Self requests are failing because the PAC > "KDC (privilege server)" checksum (which is in fact a signature) generated > by MIT krb5 is using the strongest encryption type permitted by the Kerberos > configuration. Actually it is not based on the strongest permitted encryption type setting, but on the strongest encryption type key of the krbtgt/<realm>@<realm> entry. Created attachment 1980434 [details] freeipa-4.10.2-1.fc38 no support for enctype on S4U2Proxy The pac_privsvr_enctype string attribute allowing to configure the encryption type of the KDC signature should fix this issue in krb5 1.21. However I face the following error on Fedora 38 with the freeipa-4.10.2-1.fc38 update[1]: $ KRB5_TRACE=/dev/stderr kvno -U admin -P cifs/dc-ut96.ad-ut96.test [13475] 1690302326.763953: Getting credentials admin\@IPA.TEST -> host/cli.ipa.test using ccache KCM:0 [13475] 1690302326.763954: Retrieving host/cli.ipa.test -> krb5_ccache_conf_data/start_realm@X-CACHECONF: from KCM:0 with result: -1765328243/Matching credential not found [13475] 1690302326.763955: Retrieving admin\@IPA.TEST -> host/cli.ipa.test from KCM:0 with result: 0/Success cifs/dc-ut96.ad-ut96.test: kvno = 1 [13475] 1690302326.763956: Retrieving -> cifs/dc-ut96.ad-ut96.test from KCM:0 with result: -1765328243/Matching credential not found [13475] 1690302326.763957: Getting credentials host/cli.ipa.test -> krbtgt/IPA.TEST using ccache KCM:0 [13475] 1690302326.763958: Retrieving host/cli.ipa.test -> krb5_ccache_conf_data/start_realm@X-CACHECONF: from KCM:0 with result: -1765328243/Matching credential not found [13475] 1690302326.763959: Retrieving host/cli.ipa.test -> krbtgt/IPA.TEST from KCM:0 with result: 0/Success [13475] 1690302326.763960: Get cred via TGT krbtgt/IPA.TEST after requesting cifs/dc-ut96.ad-ut96.test (canonicalize on) [13475] 1690302326.763961: Generated subkey for TGS request: aes256-cts/7285 [13475] 1690302326.763962: etypes requested in TGS request: aes256-cts, aes256-sha2, camellia256-cts, aes128-sha2, aes128-cts, camellia128-cts [13475] 1690302326.763964: Encoding request body and padata into FAST request [13475] 1690302326.763965: Sending request (4518 bytes) to AD-UT96.TEST [13475] 1690302326.763966: Sending DNS URI query for _kerberos.AD-UT96.TEST. [13475] 1690302326.763967: No URI records found [13475] 1690302326.763968: Sending DNS SRV query for _kerberos._udp.AD-UT96.TEST. [13475] 1690302326.763969: SRV answer: 0 100 88 "dc-ut96.ad-ut96.test." [13475] 1690302326.763970: Sending DNS SRV query for _kerberos._tcp.AD-UT96.TEST. [13475] 1690302326.763971: SRV answer: 0 100 88 "dc-ut96.ad-ut96.test." [13475] 1690302326.763972: Resolving hostname dc-ut96.ad-ut96.test. [13475] 1690302326.763973: Resolving hostname dc-ut96.ad-ut96.test. [13475] 1690302326.763974: Initiating TCP connection to stream 10.0.197.117:88 [13475] 1690302326.763975: Sending TCP request to stream 10.0.197.117:88 [13475] 1690302326.763976: Received answer (96 bytes) from stream 10.0.197.117:88 [13475] 1690302326.763977: Terminating TCP connection to stream 10.0.197.117:88 [13475] 1690302326.763978: Sending DNS URI query for _kerberos.AD-UT96.TEST. [13475] 1690302326.763979: No URI records found [13475] 1690302326.763980: Sending DNS SRV query for _kerberos-master._tcp.AD-UT96.TEST. [13475] 1690302326.763981: No SRV records found [13475] 1690302326.763982: Response was not from primary KDC [13475] 1690302326.763983: Got cred; -1765328370/KDC has no support for encryption type kvno: KDC has no support for encryption type cifs/dc-ut96.ad-ut96.test: constrained delegation failed The network trace is in attachment. [1] https://bodhi.fedoraproject.org/updates/FEDORA-2023-95e3fe4d76 Created attachment 1980834 [details]
freeipa-4.10.2-1.fc38 enctype accepted by AD with S4U2Proxy
Alexander told me this was caused by the fact I was providing the realm explicitly for the target principal in the kvno command. Indeed, using the "@" without the realm name causes the client to not skip the cross-realm TGT request:
$ kvno -U admin -P cifs/dc-xk57.ad-xk57.test@
CentOS Stream 9 merge request: https://gitlab.com/redhat/centos-stream/rpms/krb5/-/merge_requests/40 Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (Moderate: krb5 security and bug fix update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2023:6699 |
[root@master ~]# ipa trust-find --------------- 1 trust matched --------------- Realm name: win19-13r8.test Domain NetBIOS name: WIN19-13R8 Domain Security Identifier: S-1-5-21-3829174166-1252505095-3327585824 Trust type: Active Directory domain ---------------------------- Number of entries returned 1 ---------------------------- [root@master ~]# klist -e Ticket cache: KCM:0 Default principal: admin Valid starting Expires Service principal 03/03/2022 08:42:50 03/04/2022 08:19:50 HTTP/master.testrealm1way.test Etype (skey, tkt): aes256-cts-hmac-sha384-192, aes256-cts-hmac-sha384-192 03/03/2022 08:42:48 03/04/2022 08:19:50 krbtgt/TESTREALM1WAY.TEST Etype (skey, tkt): aes256-cts-hmac-sha384-192, aes256-cts-hmac-sha384-192 [root@master ~]# KRB5_TRACE=/dev/stderr kvno -S cifs ad1-13r8.win19-13r8.test [24932] 1646315147.757589: Getting credentials admin -> cifs/ad1-13r8.win19-13r8.test using ccache KCM:0 [24932] 1646315147.757590: Retrieving admin -> krb5_ccache_conf_data/start_realm@X-CACHECONF: from KCM:0 with result: -1765328243/Matching credential not found [24932] 1646315147.757591: Retrieving admin -> cifs/ad1-13r8.win19-13r8.test from KCM:0 with result: -1765328243/Matching credential not found [24932] 1646315147.757592: Retrieving admin -> krbtgt/WIN19-13R8.TEST from KCM:0 with result: -1765328243/Matching credential not found [24932] 1646315147.757593: Retrieving admin -> krbtgt/TESTREALM1WAY.TEST from KCM:0 with result: 0/Success [24932] 1646315147.757594: Starting with TGT for client realm: admin -> krbtgt/TESTREALM1WAY.TEST [24932] 1646315147.757595: Retrieving admin -> krbtgt/WIN19-13R8.TEST from KCM:0 with result: -1765328243/Matching credential not found [24932] 1646315147.757596: Requesting TGT krbtgt/WIN19-13R8.TEST using TGT krbtgt/TESTREALM1WAY.TEST [24932] 1646315147.757597: Generated subkey for TGS request: aes256-sha2/107C [24932] 1646315147.757598: etypes requested in TGS request: aes256-sha2, aes256-cts, aes128-sha2, aes128-cts [24932] 1646315147.757600: Encoding request body and padata into FAST request [24932] 1646315147.757601: Sending request (1948 bytes) to TESTREALM1WAY.TEST [24932] 1646315147.757602: Initiating TCP connection to stream 10.0.199.42:88 [24932] 1646315147.757603: Sending TCP request to stream 10.0.199.42:88 [24932] 1646315147.757604: Received answer (1804 bytes) from stream 10.0.199.42:88 [24932] 1646315147.757605: Terminating TCP connection to stream 10.0.199.42:88 [24932] 1646315147.757606: Response was from primary KDC [24932] 1646315147.757607: Decoding FAST response [24932] 1646315147.757608: FAST reply key: aes256-sha2/3569 [24932] 1646315147.757609: TGS reply is for admin -> krbtgt/WIN19-13R8.TEST with session key aes256-cts/349C [24932] 1646315147.757610: TGS request result: 0/Success [24932] 1646315147.757611: Received TGT for WIN19-13R8.TEST; advancing current realm [24932] 1646315147.757612: Retrieving admin -> krbtgt/WIN19-13R8.TEST from KCM:0 with result: -1765328243/Matching credential not found [24932] 1646315147.757613: Requesting TGT krbtgt/WIN19-13R8.TEST using TGT krbtgt/WIN19-13R8.TEST [24932] 1646315147.757614: Generated subkey for TGS request: aes256-cts/6248 [24932] 1646315147.757615: etypes requested in TGS request: aes256-sha2, aes256-cts, aes128-sha2, aes128-cts [24932] 1646315147.757617: Encoding request body and padata into FAST request [24932] 1646315147.757618: Sending request (1812 bytes) to WIN19-13R8.TEST [24932] 1646315147.757619: Initiating TCP connection to stream 10.0.199.57:88 [24932] 1646315147.757620: Sending TCP request to stream 10.0.199.57:88 [24932] 1646315147.757621: Received answer (331 bytes) from stream 10.0.199.57:88 [24932] 1646315147.757622: Terminating TCP connection to stream 10.0.199.57:88 [24932] 1646315147.757623: Response was from primary KDC [24932] 1646315147.757624: Decoding FAST response [24932] 1646315147.757625: TGS request result: -1765328324/Generic error (see e-text) kvno: Generic error (see e-text) while getting credentials for cifs/ad1-13r8.win19-13r8.test From krb5kdc.log: Mar 03 08:45:47 master.testrealm1way.test krb5kdc[24353](info): TGS_REQ (4 etypes {aes256-cts-hmac-sha384-192(20), aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha256-128(19), aes128-cts-hmac-sha1-96(17)}) 10.0.199.42: ISSUE: authtime 1646314968, etypes {rep=aes256-cts-hmac-sha384-192(20), tkt=aes256-cts-hmac-sha1-96(18), ses=aes256-cts-hmac-sha1-96(18)}, admin for krbtgt/WIN19-13R8.TEST I think we've seen this issue when developing krb5 1.20 upstream, so it needs to be re-verified with 1.20 when rebase happens.