Bug 2039349 - KB5008380 / CVE-2021-42287 - adcli fails during client enrollment after Microsoft patches were applied
Summary: KB5008380 / CVE-2021-42287 - adcli fails during client enrollment after Micro...
Keywords:
Status: NEW
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: adcli
Version: 8.5
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: rc
: ---
Assignee: Sumit Bose
QA Contact: sssd-qe
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2022-01-11 14:51 UTC by Thorsten Scherf
Modified: 2022-06-22 17:09 UTC (History)
32 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:
Type: Bug
Target Upstream Version:


Attachments (Terms of Use)
network trace from test environment (20.99 KB, application/vnd.tcpdump.pcap)
2022-01-14 12:57 UTC, Sumit Bose
no flags Details
keytab to decrypt part of the network trace from test system with 'wireshark -K other-ad_administrator.keytab ...' (85 bytes, application/octet-stream)
2022-01-14 12:59 UTC, Sumit Bose
no flags Details
Test build of adcli with potential fix (385.50 KB, application/gzip)
2022-01-18 08:42 UTC, Sumit Bose
no flags Details
REHL-7 test build of adcli with a potential fix (284.02 KB, application/gzip)
2022-01-25 09:46 UTC, Sumit Bose
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker RHELPLAN-107429 0 None None None 2022-01-11 14:53:04 UTC
Red Hat Issue Tracker SSSD-4335 0 None None None 2022-02-28 07:20:49 UTC
Red Hat Knowledge Base (Solution) 6633491 0 None None None 2022-01-11 15:17:19 UTC

Description Thorsten Scherf 2022-01-11 14:51:48 UTC
Description of problem:
After applying Microsoft patches to address the issue assigned to CVE-2021-42287, adcli fails with an error during the client enrollment process.
  

Version-Release number of selected component (if applicable):


How reproducible:



Steps to Reproduce:
1.
2.
3.

Actual results:

adcli fails with "Cannot set computer password: Authentication error".


Expected results:


Additional info:

https://support.microsoft.com/en-us/topic/kb5008380-authentication-updates-cve-2021-42287-9dafac11-e0d0-4cb8-959a-143bd0201041

Comment 6 Sumit Bose 2022-01-12 09:42:51 UTC
Hi,

I'm able to reproduce the issue with a fully updated AD DC where I set the registry key 'PacRequestorEnforcement' to '2' which means enforcement. According to https://support.microsoft.com/en-us/topic/kb5008380-authentication-updates-cve-2021-42287-9dafac11-e0d0-4cb8-959a-143bd0201041 the "Enforcement phase" is planned for July 12, 2022 and by default Microsoft would not set it earlier. With values '0' or '1' the join works as expected in my testings.

Can you check with the customers if they already set 'PacRequestorEnforcement' to '2'? If yes I can continue working with my local reproducer.

bye,
Sumit

Comment 11 Sumit Bose 2022-01-14 12:56:30 UTC
Hi,

to summarized, the issue occurs if the latest patches related to CVE-2021-42287 are applied _and_ the registry variable 'PacRequestorEnforcement' is set to '2' which means enforcement of the new policy. The second step has to be done manually because the current patches my Microsoft only add the new registry variable with a default of '1' (Deployment phase). The plan is to change the default to enforcement later this year.

So far I was not able to identify an particular messages in the AD event log related to the returned error. I even set LogLevel=1 to enable Kerberos logging in the registry, but I'm not sure if this controls the kpasswd service as well.

For the interested reader I will add a network trace together with a user keytab file to decode at least some part of the communication. The interesting frames are #67 which is the kpasswd request which is imo in accordance with https://datatracker.ietf.org/doc/html/rfc3244. The reply is in frame #69 with the error KRB5KDC_TGT_REVOKED and e-data '3' which corresponds to KRB5_KPASSWD_AUTHERROR of RFC-3244.

My current assumption is that a check in AD might be too strict in enforcing mode. The PAC will identify the user as Administrator while the password change is for a different user which might cause the rejection. Do a password change  for a user with the user credentials where PAC user and target user are the same is working as expect.

bye,
Sumit

Comment 12 Sumit Bose 2022-01-14 12:57:57 UTC
Created attachment 1850781 [details]
network trace from test environment

Comment 13 Sumit Bose 2022-01-14 12:59:18 UTC
Created attachment 1850782 [details]
keytab to decrypt part of the network trace from test system with 'wireshark -K other-ad_administrator.keytab ...'

Comment 15 Sumit Bose 2022-01-17 10:23:48 UTC
Hi,

David Mulder and Andrew Bartlett suggested to use LDAP operations to set the machine account password. This seems to work, there is a work-in-progress patch at https://gitlab.freedesktop.org/sbose/adcli/-/commits/PacRequestorEnforcement.

bye,
Sumit

Comment 16 Sumit Bose 2022-01-18 08:42:31 UTC
Created attachment 1851531 [details]
Test build of adcli with potential fix

Hi,

please find attached a test build of adcli with a fix which replaces the operation which is blocked when setting PacRequestorEnforcement to 2. It is working well in my test but I might not cover all use cases. Feel free to add a comment in this ticket if the test build is working for you or if there are still issues.

bye,
Sumit

Comment 17 Abhijit Roy 2022-01-18 10:05:17 UTC
Hi Sumit,

After installing the test build cus can join the domain successfully.

Case: 03112058

Comment 19 Mipe 2022-01-21 12:16:15 UTC
Hi,

I can confirm as well, with the test build I can join domain with PacRequestorEnforcement set to 2.

Thanks!

-Mipe

Comment 21 Sumit Bose 2022-01-25 09:46:16 UTC
Created attachment 1853309 [details]
REHL-7 test build of adcli with a potential fix

Hi,

please find attached a RHEL-7 test build of adcli with the same fix as the RHEL-8 test build.

bye,
Sumit

Comment 24 Voja Molan 2022-01-27 10:16:16 UTC
Works very well on RHEL-7 with a Server 2019 AD, thank you.

Comment 25 johnson.jon 2022-02-08 14:56:35 UTC
Any word on when these fixes will be bundled so we can get them downloaded and installed from a repo?

Comment 27 Ivar Bernes 2022-02-17 11:51:49 UTC
As a repeat on Jon Johnsons question; any ETA on when the fixes will be available in the normal repos?

Comment 28 dmulder 2022-02-17 15:03:05 UTC
I'll point out that MS has stated (on Feb 3) that they are working on a fix for this from there side.

Comment 29 Ivar Bernes 2022-02-18 08:03:07 UTC
(In reply to dmulder from comment #28)
> I'll point out that MS has stated (on Feb 3) that they are working on a fix
> for this from there side.

Aha, that is good I guess. I'm unable to google up said statement or information about it though, is there a public url that you can share please?

Comment 30 Abhijit Roy 2022-02-28 13:18:41 UTC
Hi,

Are we going to fix this BZ or we are waiting for MS?

Comment 33 johnson.jon 2022-03-07 17:56:30 UTC
Our microsoft contact within the company mentioned they aren't planning to fix the issues for third parties exhibiting issues. It sounds like we need RH to get this bundled and deployed. Can we get someone to confirm?

Comment 34 Thorsten Scherf 2022-03-11 09:55:24 UTC
In KB article https://support.microsoft.com/en-gb/topic/kb5008380-authentication-updates-cve-2021-42287-9dafac11-e0d0-4cb8-959a-143bd0201041 Microsoft acknowledged the problem in the "Known issues" section at the bottom at the page. There they also say: "Microsoft is investigating this issue. In the meantime, temporarily avoid setting PacRequestorEnforcement = 2 on affected environments."


Note You need to log in before you can comment on or make changes to this bug.