Bug 2039349

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

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

Created attachment 1850781 [details]
network trace from test environment

Created attachment 1850782 [details]
keytab to decrypt part of the network trace from test system with 'wireshark -K other-ad_administrator.keytab ...'

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

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

Hi Sumit,

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

Case: 03112058

Hi,

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

Thanks!

-Mipe

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

Works very well on RHEL-7 with a Server 2019 AD, thank you.

Any word on when these fixes will be bundled so we can get them downloaded and installed from a repo?

As a repeat on Jon Johnsons question; any ETA on when the fixes will be available in the normal repos?

I'll point out that MS has stated (on Feb 3) that they are working on a fix for this from there side.

(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?

Hi,

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

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?

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."

Hi,

to my understanding this issue should be fixed with Microsoft's April 2022 updates.

In my tests joining with adcli is working fine with a fully patched AD DC which include the April 2022 update with PacRequestorEnforcement 2. Unfortunately I have not found a reference in MSFT's update documents mentioning the fix explicitly.

According to https://support.microsoft.com/en-us/topic/kb5008380-authentication-updates-cve-2021-42287-9dafac11-e0d0-4cb8-959a-143bd0201041 the plan is to make PacRequestorEnforcement 1 the lowest possible level on July 12th. Please note that adcli was always working with PacRequestorEnforcement 1 even if only the AD DC updates from November 2021 were applied. adcli only failed with level 2 before April 2022 updates.

HTH

bye,
Sumit

(In reply to Sumit Bose from comment #62)
> Hi,
> 
> to my understanding this issue should be fixed with Microsoft's April 2022
> updates.
> 
> In my tests joining with adcli is working fine with a fully patched AD DC
> which include the April 2022 update with PacRequestorEnforcement 2.
> Unfortunately I have not found a reference in MSFT's update documents
> mentioning the fix explicitly.

The MSFT document now explicitly points out which updates to apply to get rid of the regression that was introduced with the November 2021 updates:

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

Hi,

given the issue is documented and fixed by Microsoft I close this ticket. Please reopen it in case the issue persists even if all updates recommended in https://support.microsoft.com/en-us/topic/kb5008380-authentication-updates-cve-2021-42287-9dafac11-e0d0-4cb8-959a-143bd0201041 are applied on the AD DCs.

bye,
Sumit