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):
Steps to Reproduce:
adcli fails with "Cannot set computer password: Authentication error".
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.
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.
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 ...'
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.
Created attachment 1851531 [details]
Test build of adcli with potential fix
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.
After installing the test build cus can join the domain successfully.
I can confirm as well, with the test build I can join domain with PacRequestorEnforcement set to 2.
Created attachment 1853309 [details]
REHL-7 test build of adcli with a potential fix
please find attached a RHEL-7 test build of adcli with the same fix as the RHEL-8 test build.
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?
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."