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

Matteo Fracassetti 26 Reputation points
2022-01-14T18:30:01.08+00:00

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?

Active Directory
Active Directory
A set of directory-based technologies included in Windows Server.
5,805 questions
0 comments

9 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Matteo Fracassetti 26 Reputation points
    2022-01-20T18:22:46.893+00:00

    Hi.

    On both on Oracle Linux 7 and 8 (and RHEL8) we have this version:

    '# msktutil -v
    msktutil version 1.1

    I created a kerberos token for a service account used to join vm to AD domain using ktutil and kiniting that token to run msktutil.

    '# ktutil
    ktutil: addent -password -p serviceuser_name@ssss .COM -k 1 -e RC4-HMAC
    Password for serviceuser_name@ssss .COM:
    ktutil: wkt /tmp/serviceuser_name.keytab
    ktutil: q
    '# klist -k -t /tmp/serviceuser_name.keytab
    Keytab name: FILE:/tmp/serviceuser_name..keytab
    KVNO Timestamp Principal

    1 01/20/2022 19:15:47 serviceuser_name.@ssss .COM

    Then I copied this token on the vm we need to join to our domain and kiniting it to run msktutils:

    '# kinit --request-pac -k -t /tmp/<serviceuser_name>.keytab <serviceuser_name>@ssss .COM | msktutil create -h $COMPUTER --computer-name $COMPUTER --server $DC --realm EXAMPLE.COM --user-creds-only --verbose

    This creates the default host keytab /etc/krb5.keytab and I can run run adcli to verify the join:

    adcli testjoin -S $DC -K /etc/krb5.keytab

    1 person found this answer helpful.
    0 comments
  2. Dave Patrick 426K Reputation points MVP
    2022-01-14T18:31:56.5+00:00

    Patch all the domain controllers as first step. Then each user will get the new improved authentication information PACs of Kerberos Ticket-Granting Tickets. (TGT) described in the KB

    Then it looks like you may get one warning for every user.

    https://support.microsoft.com/en-us/topic/kb5008380-authentication-updates-cve-2021-42287-9dafac11-e0d0-4cb8-959a-143bd0201041
    Adds the new PAC to users who authenticated using an Active Directory domain controller that has the November 9, 2021 or later updates installed. When authenticating, if the user has the new PAC, the PAC is validated.

    the PacRequestorEnforcement registry value's only function is to allow you to transition to the Enforcement phase early. Otherwise not needed.

    --please don't forget to upvote and Accept as answer if the reply is helpful--

    0 comments
  3. Matteo Fracassetti 26 Reputation points
    2022-01-14T18:53:58.77+00:00

    Hi, thank you for your reply.

    All DCs are fully updated to 12-2021 since a couple of weeks, I inspected our logs to monitor event ID 35,36 and 37 for a while then move the PacRequestorEnforcement regkey to "2" to enforce the PAC management and verify what happens to our infrastructure.

    This is the issue: When the enforcement phase will starts in July, we will lose the ability to join new Linux VMs to our AD Domain if I'm not doing something wrong now or if I haven't misunderstood something.

    User's Kerberos keytab used to test joining the VM to domain was generated now, so they are new.
    So seems that adcli don't send to DCs the info related to PACs that should be present in the keytab or that I haven't understand that some other steps are required to grant my user to join workstation to domain after the "Enforcement Phase" will starts.
    I can reproduce the same issue also using domain administrator account so I think this is not a permission issue but something on the new computer object related to PACs evaluation.

    0 comments
  4. Dave Patrick 426K Reputation points MVP
    2022-01-14T19:04:57.383+00:00

    Not finding a lot of info on how Linux may address this one. May need to ask in Linux forums for help on that side.

    --please don't forget to upvote and Accept as answer if the reply is helpful--

    0 comments
  5. Matteo Fracassetti 26 Reputation points
    2022-01-14T19:06:49.563+00:00

    For example:

    root@test-pac:~ # realm join --verbose AD.DOMAIN.COM -U 'administrator@AD.DOMAIN.COM'
    * Resolving: _ldap._tcp.ad.domain.com
    * Performing LDAP DSE lookup on: 10.248.48.1
    * Performing LDAP DSE lookup on: 10.248.200.10
    * Successfully discovered: AD.DOMAIN.COM
    Password for administrator@AD.DOMAIN.COM:
    * Required files: /usr/sbin/oddjobd, /usr/libexec/oddjob/mkhomedir, /usr/sbin/sssd, /usr/sbin/adcli
    * LANG=C /usr/sbin/adcli join --verbose --domain AD.DOMAIN.COM --domain-realm AD.DOMAIN.COM --domain-controller 10.248.48.1 --login-type user --login-user administrator@AD.DOMAIN.COM --stdin-password
    * Using domain name: AD.DOMAIN.COM
    * Calculated computer account name from fqdn: TEST-PAC
    * Using domain realm: AD.DOMAIN.COM
    * Sending NetLogon ping to domain controller: 10.248.48.1
    * Received NetLogon info from: DC02.AD.DOMAIN.COM
    * Wrote out krb5.conf snippet to /var/cache/realmd/adcli-krb5-pZBfLs/krb5.d/adcli-krb5-conf-bMsr5s
    * Authenticated as user: administrator@AD.DOMAIN.COM
    * 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: 10.248.48.1
    * Received NetLogon info from: DC02.AD.DOMAIN.COM
    ! Cannot set computer password: Authentication error
    adcli: joining domain AD.DOMAIN.COM failed: Cannot set computer password: Authentication error
    Please check
    https://red.ht/support_rhel_ad
    to get help for common issues.
    ! Insufficient permissions to join the domain
    realm: Couldn't join realm: Insufficient permissions to join the domain
    Please check
    https://red.ht/support_rhel_ad
    to get help for common issues.

    Here I'm not using kerberos keytab to join my workstation to domain but I'm simply using password auth for user "Administrator".
    Everithings goes fine and the new computer object is created in AD but when the join procedure try to update the password of the newly created computer object it got an error. This don't happens when "PacRequestorEnforcement" is not enforced.

    0 comments