Bug 2016312
| Summary: | Rebase krb5 to latest upstream release 1.20 [rhel-9] | |||
|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 9 | Reporter: | Alexander Bokovoy <abokovoy> | |
| Component: | krb5 | Assignee: | Julien Rische <jrische> | |
| Status: | CLOSED ERRATA | QA Contact: | Filip Dvorak <fdvorak> | |
| Severity: | unspecified | Docs Contact: | Filip Hanzelka <fhanzelk> | |
| Priority: | unspecified | |||
| Version: | 9.0 | CC: | antorres, fdvorak, frenaud, gkaihoro, jrische, ndehadra, sam | |
| Target Milestone: | rc | Keywords: | Rebase, Triaged | |
| Target Release: | --- | |||
| Hardware: | Unspecified | |||
| OS: | Unspecified | |||
| Whiteboard: | ||||
| Fixed In Version: | krb5-1.20.1-3.el9 | Doc Type: | Known Issue | |
| Doc Text: |
.MIT `krb5` user fails to obtain an AD TGT because of incompatible encryption types generating the user PAC
In MIT `krb5 1.20` and later packages, a Privilege Attribute Certificate (PAC) is included in all Kerberos tickets by default. The MIT Kerberos Distribution Center (KDC) selects the strongest encryption type available to generate the KDC checksum in the PAC, which currently is the `AES HMAC-SHA2` encryption types defined in RFC8009. However, Active Directory (AD) does not support this RFC. Consequently, in an AD-MIT cross-realm setup, an MIT `krb5` user fails to obtain an AD ticket-granting ticket (TGT) because the cross-realm TGT generated by MIT KDC contains an incompatible KDC checksum type in the PAC.
To work around the problem, set the `disable_pac` parameter to `true` for the MIT realm in the `[realms]` section of the `/var/kerberos/krb5kdc/kdc.conf` configuration file. As a result, the MIT KDC generates tickets without PAC, which means that AD skips the failing checksum verification and an MIT `krb5` user can obtain an AD TGT.
|
Story Points: | --- | |
| Clone Of: | ||||
| : | 2124463 (view as bug list) | Environment: | ||
| Last Closed: | 2023-05-09 08:25:24 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: | ||||
| Bug Blocks: | 1956994, 2060421, 2068535, 2114771, 2124463, 2155425, 2209621 | |||
| Deadline: | 2022-08-01 | |||
| Attachments: | ||||
|
Description
Alexander Bokovoy
2021-10-21 09:26:15 UTC
Since krb5 1.20 is not yet tagged and in discussion with upstream it is going to be released somewhere during spring 2022, wewould move the rebase forward to next possible development version of RHEL 9. The krb5 1.20 rebase is available here: https://src.fedoraproject.org/fork/jrische/rpms/krb5/tree/krb5-1.20 Tests are failing for Fedora 35, but it seems related to a change in glibc affecting resolv_wrapper, which is used in tests for KDC DNS lookup: https://gitlab.com/cwrap/resolv_wrapper/-/commit/c75587f858eb49e6b13ab610e63289df0485ddac AD/MIT cross-realm seems to be broken since version 1.20 (tested on Fedora and C9S/RHEL against Windows Server 2019). An AD principal is able to request a ticket for the an MIT principal, but the opposite fails with a generic error (without e-text). This issue persists even when PAC is disabled on MIT KDC. It seems to be related to the content of the MIT TGT, because after pre-authentication using krb5 1.20 and downgrading to 1.19.*, the cross-realm TGT TGS-REQ succeed, but the service ticket TGS-REQ will continue to fail until the ccache is destroyed and the TGT requested again. No obvious different is visible in the network capture. C9S pull request: https://gitlab.com/redhat/centos-stream/rpms/krb5/-/merge_requests/23 Created attachment 1910256 [details]
Capture of cross-realm TGS-REQ with krb5-1.19.2-11.fc36
Created attachment 1910257 [details]
Capture of cross-realm TGS-REQ with krb5-1.20-0.12.fc36
This is the diff between MIT/AD cross-realm TGS-REQs for krb5 versions 1.19.2 and 1.20. The first one succeeds, while the second one fails with a generic error.
@@ -5,7 +5,7 @@
padata: 2 items
PA-DATA pA-TGS-REQ
padata-type: pA-TGS-REQ (1)
- padata-value: 6e82020f3082020ba003020105a10302010ea20703050000000000a38201306182012c30…
+ padata-value: 6e8202c4308202c0a003020105a10302010ea20703050000000000a38201e4618201e030…
ap-req
pvno: 5
msg-type: krb-ap-req (14)
@@ -25,7 +25,7 @@
enc-part
etype: eTYPE-AES256-CTS-HMAC-SHA1-96 (18)
kvno: 1
- cipher: 77e00f5e94d1115b0d88e31e3a0c9fe77d81af2c17fd0b48f3de7bf4c3bc506920a7503c…
+ cipher: 91324c3d3d9955b9685a60124b2bc7732f847debb3f3b03c7e8192c21a66fa834bf5e98a…
encTicketPart
Padding: 0
flags: 40a90000
@@ -47,9 +47,8 @@
.... ...1 = enc-pa-rep: True
0... .... = anonymous: False
key
- Learnt encTicketPart_key keytype 18 (id=7.1) (48df8b57...)
keytype: 18
- keyvalue: 48df8b578eb742a17e3053d36a9dd41160c60c5159ff86f985c05fa0ce4bd052
+ keyvalue: d853d5ed474bc542278ddd258e164bbfd047367ffc43059993c033216e906887
crealm: MIT.TEST
cname
name-type: kRB5-NT-SRV-HST (3)
@@ -59,13 +58,41 @@
transited
tr-type: 1
contents: <MISSING>
- authtime: 2022-09-07 15:18:26 (UTC)
- starttime: 2022-09-07 15:18:29 (UTC)
- endtime: 2022-09-08 15:18:26 (UTC)
- renew-till: 2022-09-07 15:18:26 (UTC)
+ authtime: 2022-09-07 15:27:53 (UTC)
+ starttime: 2022-09-07 15:28:02 (UTC)
+ endtime: 2022-09-08 15:27:53 (UTC)
+ renew-till: 2022-09-07 15:27:53 (UTC)
+ authorization-data: 1 item
+ AuthorizationData item
+ ad-type: aD-IF-RELEVANT (1)
+ ad-data: 308197308194a00402020080a1818b04818803000000000000000a0000002c0000003800…
+ AuthorizationData item
+ ad-type: aD-WIN2K-PAC (128)
+ ad-data: 03000000000000000a0000002c0000003800000000000000060000001000000068000000…
+ Num Entries: 3
+ Version: 0
+ Type: Client Info Type (10)
+ Size: 44
+ Offset: 56
+ PAC_CLIENT_INFO_TYPE: 80a28965cec2d801220068006f00730074002f006b00640063002e006d00690074002e00…
+ ClientID: Sep 7, 2022 17:27:53.000000000 CEST
+ Name Length: 34
+ Name: host/kdc.mit.test
+ Type: Server Checksum (6)
+ Size: 16
+ Offset: 104
+ PAC_SERVER_CHECKSUM: 10000000122529dc2f4af00a9cb1b2a1
+ Type: 16
+ Signature: 122529dc2f4af00a9cb1b2a1
+ Type: Privsvr Checksum (7)
+ Size: 16
+ Offset: 120
+ PAC_PRIVSVR_CHECKSUM: 1000000008cc7a0e8488d11683250f22
+ Type: 16
+ Signature: 08cc7a0e8488d11683250f22
authenticator
etype: eTYPE-AES256-CTS-HMAC-SHA1-96 (18)
- cipher: 6da3ec7e6afcff86281f122eb71937a481971c123df920c69241d14773f60b4359d9cd14…
+ cipher: b75c3350d9acd7d8c5838319986544af5de5dc3cfc9ed6efba3b3669e09c2a2cd8f1f24b…
authenticator
authenticator-vno: 5
crealm: MIT.TEST
@@ -76,22 +103,22 @@
CNameString: kdc.mit.test
cksum
cksumtype: cKSUMTYPE-HMAC-SHA1-96-AES-256 (16)
- checksum: 494d07247e5279832f7d2168
- cusec: 574
- ctime: 2022-09-07 15:18:29 (UTC)
+ checksum: dbba2d36ecdb1508344b991a
+ cusec: 312591
+ ctime: 2022-09-07 15:28:02 (UTC)
subkey
keytype: 18
- keyvalue: 10baa6c2d4dd0ce0e0dab2bda3de1a9ea2a11e243f17117b0ce86d34e51ebb96
+ keyvalue: 2a6402376037f205d346aead5fdde0ca359285f3e114083b4dbc70e18ce1c0d3
PA-DATA pA-FX-FAST
padata-type: pA-FX-FAST (136)
- padata-value: a081d03081cda1173015a003020110a10e040cace53cf533abb08393c4a3b9a281b13081…
+ padata-value: a081d03081cda1173015a003020110a10e040cd8a3c74e3edc4c158a72356aa281b13081…
armored-data
req-checksum
cksumtype: cKSUMTYPE-HMAC-SHA1-96-AES-256 (16)
- checksum: ace53cf533abb08393c4a3b9
+ checksum: d8a3c74e3edc4c158a72356a
enc-fast-req
etype: eTYPE-AES256-CTS-HMAC-SHA1-96 (18)
- cipher: 2e1edb8ed23b932e5ee7d0f549df9332adf6a9964c6edea51546e68ff18d81b39931c175…
+ cipher: 48b8be10180b6f753bb95680b23f0164dab47fc8d22c449388bb99d0149a847842220b82…
Padding: 0
fast-options: 00000000
0... .... = reserved: False
@@ -114,7 +141,7 @@
padata: 0 items
req-body
Padding: 0
- kdc-options: 40810000
+ kdc-options: 40800000
0... .... = reserved: False
.1.. .... = forwardable: True
..0. .... = forwarded: False
@@ -130,7 +157,7 @@
.... 0... = unused12: False
.... .0.. = unused13: False
.... ..0. = constrained-delegation: False
- .... ...1 = canonicalize: True
+ .... ...0 = canonicalize: False
0... .... = request-anonymous: False
.0.. .... = unused17: False
..0. .... = unused18: False
@@ -153,8 +180,8 @@
sname-string: 2 items
SNameString: cifs
SNameString: dc-ygq0.ad-ygq0.test
- till: 2022-09-08 15:18:26 (UTC)
- nonce: 1231587260
+ till: 2022-09-08 15:27:53 (UTC)
+ nonce: 1015010219
etype: 6 items
ENCTYPE: eTYPE-AES256-CTS-HMAC-SHA1-96 (18)
ENCTYPE: eTYPE-AES256-CTS-HMAC-SHA384-192 (20)
@@ -164,7 +191,7 @@
ENCTYPE: eTYPE-CAMELLIA128-CTS-CMAC (25)
req-body
Padding: 0
- kdc-options: 40810000
+ kdc-options: 40800000
0... .... = reserved: False
.1.. .... = forwardable: True
..0. .... = forwarded: False
@@ -180,7 +207,7 @@
.... 0... = unused12: False
.... .0.. = unused13: False
.... ..0. = constrained-delegation: False
- .... ...1 = canonicalize: True
+ .... ...0 = canonicalize: False
0... .... = request-anonymous: False
.0.. .... = unused17: False
..0. .... = unused18: False
@@ -203,8 +230,8 @@
sname-string: 2 items
SNameString: cifs
SNameString: dc-ygq0.ad-ygq0.test
- till: 2022-09-08 15:18:26 (UTC)
- nonce: 1231587260
+ till: 2022-09-08 15:27:53 (UTC)
+ nonce: 1015010219
etype: 6 items
ENCTYPE: eTYPE-AES256-CTS-HMAC-SHA1-96 (18)
ENCTYPE: eTYPE-AES256-CTS-HMAC-SHA384-192 (20)
The only difference seems to be the presence of the PAC and the fact the "canonicalize" flag is not longer set. My bad, after the first generic error, the client retries the same TGS-REQ with "canonicalize" off, but in the initial request canonicalization is enabled. So the only difference is the PAC. I've tried to run the same process with "disable_pac = true" in the KDC configuration, but the PAC is still there. The solution is the set +no_auth_data_required for the cross realm principal "krbtgt/[AD realm]@[MIT realm]". This way the PAC is actually removed from the TGS-REQ to AD and the request succeeds. This point should definitely be documented, because I don't think we can deal with it in the KDC configuration. Users will have to set the no_auth_data_required flag for the cross-realm principal themselves in version 1.20. Created attachment 1910275 [details]
Capture of successful MIT/AD cross-realm exchange (no PAC) with krb5-1.20-0.12.fc36 and Windows Server 2019
The whole idea of 1.20 was that a minimal PAC is being sent by the KDC now for all cases. It is a security measure. If this PAC is not accepted anymore, we should find out why this happens and fix it. Are we sure this PAC was ever accepted by AD's realm trust (not the external nor forest ones)? Maybe this kind of trust is meant to work as a vanilla cross-realm without the Microsoft extensions. That is a good question. I think we need to review Microsoft's Product Security bulletins when fixes for the following CVEs were released: * CVE-2021-42291: Active Directory Domain Services Elevation of Privilege Vulnerability, Active Directory permissions updates, https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2021-42291 * CVE-2021-42287: Active Directory Domain Services Elevation of Privilege Vulnerability, Authentication updates, https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2021-42287 * CVE-2021-42282: Active Directory Domain Services Elevation of Privilege Vulnerability, Verification of uniqueness for user principal name, service principal name, and the service principal name alias, https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2021-42282 * CVE-2021-42278: Active Directory Domain Services Elevation of Privilege Vulnerability, Active Directory Security Accounts Manager hardening changes, https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2021-42278 Created attachment 1910496 [details]
Capture of failing MIT/AD cross-realm exchange with krb5-1.20-0.12.fc36 and Windows Server 2019
Created attachment 1910497 [details]
Keytab of failing MIT/AD cross-realm exchange with krb5-1.20-0.12.fc36 and Windows Server 2019
I made in mistake in my KDC configuration template: "disable_pac = true" actually removes the PAC from tickets, as expected. Created attachment 1911213 [details]
trace for IPA client attempting to S4U2Self of AD user over two-way trust
Attached is my trace of
kinit -k
kvno -U administrator host/master.ipa.test
There is extracted error part of the response from AD DC which bears unknown ASN.1 response which contradicts MS-KILE 2.2.1 and 2.2.2 where a `data-type` value could be 2 or 3 but we get 136.
In version 1.20, the call to dlopen() to load the PKCS11 module file has been replaced by a call to krb5int_open_plugin()[1]. As a consequence, it is no longer possible to rely on the dynamic library lookup path to load the module using its filename alone. Which means an absolute (or relative) path to the module file is now required. We should decide if we consider the possibility to use module filename alone as a requirement of not. If the answer is yes, the next question is: Should the lookup path simply be /usr/lib64/pkcs11 or all the dynamic library paths, which may be difficult to define[2]? [1] https://github.com/krb5/krb5/commit/c5c11839e02c7993eb78f2c94c75c10cf93f2195 [2] https://man7.org/linux/man-pages/man8/ld.so.8.html#DESCRIPTION Message on CIFS protocol mailing list about PAC compliance issue in AD cross-realm setup: https://lists.samba.org/archive/cifs-protocol/2022-September/003751.html 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, bug fix, and enhancement 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:2570 |