Microsoft KB5008380 for CVE-2021-42287: Unable to join Linux vm to AD domain when in "Enforcement phase".

Question

After installing the hotfix for CVE-2021-42287 on our Windows 2019 DCs, if "PacRequestorEnforcement" has been set to "2" (enabling th "Enforcement phase") we became unable to join our Oracle Linux 8 VM (RHEL based) to our AD domain (tested on OL8 vm fully updated).
I tryed both "realm" or "adcli" with the same results and we get an "authentication error" after the computer account was created in AD (so we are able to create a new computer object but the join procedure fails while setting the computer account password, leaving the VM not joined to AD domain because the password isn't set nor the computer keytab is generated) and with an orphan computer object in AD.

This issue seems to be quite relevant but I can't find so much information on internet so I think I'm loosing something of obvious...

This is with "PacRequestorEnforcement" set to "1":

root@test-pac:~ # /usr/bin/kinit -V -R -k -t /tmp/user.keytab -c /tmp/cred_cache_file --request-pac user@AD.DOMAIN.COM | /usr/sbin/adcli join --no-password -D AD.DOMAIN.COM -S dc01vm.ad.domain.com -U user@AD.DOMAIN.COM --login-ccache=/tmp/cred_cache_file -v --show-details
Using specified cache: /tmp/cred_cache_file
Using principal: user@AD.DOMAIN.COM
Using keytab: /tmp/user.keytab
* Using domain name: AD.DOMAIN.COM
* Calculated computer account name from fqdn: TEST-PAC
* Calculated domain realm from name: AD.DOMAIN.COM
* Sending NetLogon ping to domain controller: dc01vm.ad.domain.com
Authenticated to Kerberos v5
* Received NetLogon info from: DC01VM.AD.DOMAIN.COM
* Wrote out krb5.conf snippet to /tmp/adcli-krb5-Fp32Eu/krb5.d/adcli-krb5-conf-9KzKou
* Using GSS-SPNEGO for SASL bind
* Looked up short domain name: AD
* Looked up domain SID: S-1-5-21-994023112-3112520415-3963116401
* Using fully qualified name: test-pac.ad.domain.com
* Using domain name: AD.DOMAIN.COM
* Using computer account name: TEST-PAC
* Using domain realm: AD.DOMAIN.COM
* Calculated computer account name from fqdn: TEST-PAC
* Generated 120 character computer password
* Using keytab: FILE:/etc/krb5.keytab
* A computer account for TEST-PAC$ does not exist
* Found well known computer container at: CN=Computers,DC=AD,DC=DOMAIN,DC=COM
* Calculated computer account: CN=TEST-PAC,CN=Computers,DC=AD,DC=DOMAIN,DC=COM
* Encryption type [16] not permitted.
* Encryption type [3] not permitted.
* Encryption type [1] not permitted.
* Created computer account: CN=TEST-PAC,CN=Computers,DC=AD,DC=DOMAIN,DC=COM
* Sending NetLogon ping to domain controller: dc01vm.ad.domain.com
* Received NetLogon info from: DC01VM.AD.DOMAIN.COM
* Set computer password
* Retrieved kvno '2' for computer account in directory: CN=TEST-PAC,CN=Computers,DC=AD,DC=DOMAIN,DC=COM
* Checking RestrictedKrbHost/test-pac.ad.domain.com
* Added RestrictedKrbHost/test-pac.ad.domain.com
* Checking RestrictedKrbHost/TEST-PAC
* Added RestrictedKrbHost/TEST-PAC
* Checking host/test-pac.ad.domain.com
* Added host/test-pac.ad.domain.com
* Checking host/TEST-PAC
* Added host/TEST-PAC
* Discovered which keytab salt to use
* Added the entries to the keytab: TEST-PAC$@AD.DOMAIN.COM: FILE:/etc/krb5.keytab
* Added the entries to the keytab: host/TEST-PAC@AD.DOMAIN.COM: FILE:/etc/krb5.keytab
* Added the entries to the keytab: host/test-pac.ad.domain.com@AD.DOMAIN.COM: FILE:/etc/krb5.keytab
* Added the entries to the keytab: RestrictedKrbHost/TEST-PAC@AD.DOMAIN.COM: FILE:/etc/krb5.keytab
* Added the entries to the keytab: RestrictedKrbHost/test-pac.ad.domain.com@AD.DOMAIN.COM: FILE:/etc/krb5.keytab
[domain]
domain-name = AD.DOMAIN.COM
domain-realm = AD.DOMAIN.COM
domain-controller = dc01vm.ad.domain.com
domain-short = AD
domain-SID = S-1-5-21-994023112-3112520415-3963116401
naming-context = DC=AD,DC=DOMAIN,DC=COM
domain-ou = (null)
[computer]
host-fqdn = test-pac.ad.domain.com
computer-name = TEST-PAC
computer-dn = CN=TEST-PAC,CN=Computers,DC=AD,DC=DOMAIN,DC=COM
os-name = redhat-linux-gnu
[keytab]
kvno = 2
keytab = FILE:/etc/krb5.keytab

root@test-pac:~ # adcli update --show-details --login-ccache=/tmp/cred_cache_file --host-fqdn=$HOSTNAME
[domain]
domain-name = ad.domain.com
domain-realm = AD.DOMAIN.COM
domain-controller = dc04vm.ad.domain.com
domain-short = AD
domain-SID = S-1-5-21-994023112-3112520415-3963116401
naming-context = DC=AD,DC=DOMAIN,DC=COM
domain-ou = (null)
[computer]
host-fqdn = test-pac.ad.domain.com
computer-name = TEST-PAC
computer-dn = CN=TEST-PAC,CN=Computers,DC=AD,DC=DOMAIN,DC=COM
os-name = redhat-linux-gnu
[keytab]
kvno = -1
keytab = FILE:/etc/krb5.keytab

and this is with "PacRequestorEnforcement" set to "2":

root@TEST-PAC:~ # kinit --request-pac -k -t /tmp/user.keytab user@AD.DOMAIN.COM | /usr/sbin/adcli join -D AD.DOMAIN.COM -S dc01vm.ad.domain.com -U user@AD.DOMAIN.COM --login-ccache=/tmp/ad.domain.com -v
* Using domain name: ad.domain.com
* Calculated computer account name from fqdn: TEST-PAC
* Calculated domain realm from name: AD.DOMAIN.COM
* Sending NetLogon ping to domain controller: dc01vm.ad.domain.com
* Received NetLogon info from: DC01VM.AD.DOMAIN.COM
* Wrote out krb5.conf snippet to /tmp/adcli-krb5-W5N5fG/krb5.d/adcli-krb5-conf-giTsVF
* Using GSS-SPNEGO for SASL bind
* Looked up short domain name: AD
* Looked up domain SID: S-1-5-21-994023112-3112520415-3963116401
* Using fully qualified name: TEST-PAC.ad.domain.com
* Using domain name: ad.domain.com
* Using computer account name: TEST-PAC
* Using domain realm: ad.domain.com
* Calculated computer account name from fqdn: TEST-PAC
* Generated 120 character computer password
* Using keytab: FILE:/etc/krb5.keytab
* A computer account for TEST-PAC$ does not exist
* Found well known computer container at: CN=Computers,DC=AD,DC=DOMAIN,DC=COM
* Calculated computer account: CN=TEST-PAC,CN=Computers,DC=AD,DC=DOMAIN,DC=COM
* Encryption type [16] not permitted.
* Encryption type [3] not permitted.
* Encryption type [1] not permitted.
* Created computer account: CN=TEST-PAC,CN=Computers,DC=AD,DC=DOMAIN,DC=COM
* Sending NetLogon ping to domain controller: dc01vm.ad.domain.com
* Received NetLogon info from: DC01VM.AD.DOMAIN.COM
! Cannot set computer password: Authentication error
adcli: joining domain ad.domain.com failed: Cannot set computer password: Authentication error

The same behaviour happens using the "administrator" account, we got the computer account in AD but an "Authentication error" while setting the computer password so the computer password is not set and nor the kerberos keytab is generated on the vm.

I had some difficult on Linux to dump the PAC of a full working keytab to inspect it but I also tried to produce the "user.keytab" on a Windows machine (DC01VM) and moving it on the Linux VM to be sure it contains PACs and I get the same result, so appear that nor adcli nor realm (which uses adcli to join the domain) are able to manage the PacRequestorEnforcement phase.

I'm loosing something about or is a known issue?

Answer 1

I can confirm the issue also on RHEL8.5 (as expected).

After some testing, I was able to use msktutils to join my VM to domain instead of "realm" or "adcli" and it works as expected even with "PacRequestorEnforcement" regkey set to "2".

Answer 2

I'm sorry: I have some doubt about encryption used to create the service token.

I've done some other tests now and seem that "aes256-cts-hmac-sha1-96" doesn't work so I recreate the token using RC4-HMAC and it worked again. I've edited my previous post.

Answer 3

I was able to create a working token using "aes256-cts-hmac-sha1-96" crypto but not using ktutil on Linux.

I created the user's keytab on a Windows DCs using ktpass:

ktpass /out "Desktop\<serviceuser_name>.keytab" /princ "<serviceuser_name>@<REALM>" /pass <user_pwd> /mapuser <serviceuser_name> /kvno 1 /Target <domain_controller> /crypto AES256-SHA1 /ptype KRB5_NT_PRINCIPAL

It could return an error but it should be safely ignored.

I can now copy this keytab on a Linux server and kiniting successfully even with Kerberos RC4 encryption disabled via GPO on domain:

'# klist -k -t <serviceuser_name>.keytab
Keytab name: FILE:<serviceuser_name>.keytab
KVNO Timestamp Principal

---

1 01/01/1970 01:00:00 <serviceuser_name>@<REALM>

'# kinit -V --request-pac -k -t <serviceuser_name>.keytab <serviceuser_name>@<REALM>
Using default cache: /tmp/krb5cc_0
Using principal: <serviceuser_name>@<REALM>
Using keytab: <serviceuser_name>.keytab
Authenticated to Kerberos v5 <<=== OK!!

'# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: <serviceuser_name>@<REALM>

Valid starting Expires Service principal
01/31/2022 12:37:08 01/31/2022 22:37:08 krbtgt/<REALM>@<REALM>
renew until 02/07/2022 12:37:08

Answer 4

Has anyone retested this since the April 2022 patches were released? I saw a potential fix included in the patch notes.

Windows Server 2022 – KB5011558

Windows Server 2019 - KB5011551

Windows Server 2016 - KB5012596

Windows Server 2012 R2 - KB5012670