Windows Server 2019 Updates Impacting Active Directory: Part 2

The November 9, 2021 “Patch Tuesday” update to Windows Server 2019 includes four updates to the way Active Directory behaves. Two of these are discussed below.

This is part 2 of changes to Active Directory behavior by the Nov 9, 2021 “Patch Tuesday” update to Windows Server 2019. Find Part 1 here.

KB5008102—Active Directory Security Accounts Manager hardening changes (CVE-2021-42278)

By default, all computer objects are created with a trailing $ in the samAccountName. It is possible for an administrator to remove the trailing $. I have seen environments where the computer object has been named–or more likely renamed–and the trailing $ is removed. Normally, this escapes the notice of administrators since the computer object otherwise behaves normally. The biggest impact this causes is that the computer doesn’t appear as a computer object in ADUC – so it might escape an administrator’s notice.

Once this patch is applied, any domain computer that does not have a samAccountName ending with the ‘$’ character will fail to authenticate to the domain and users will not be able to logon or access services.

Microsoft provides two scripts that you can use to detect these computers. This PowerShell command will get all the computer objects and display the details of a computer whose name does not end with ‘$’.

Get-ADComputer -LDAPFilter "(samAccountName=*)" |? SamAccountName -NotLike "*$" | select DNSHostName, Name, SamAccountName

To find computer accounts that have a non-compliant UserAccountControl value:

Get-ADComputer -LDAPFilter "(UserAccountControl:1.2.840.113556.1.4.803:=512)"

Read more here.

KB5008382—Verification of uniqueness for user principal name, service principal name, and the service principal name alias (CVE-2021-42282)

Many think it is not possible to add a duplicate userPrincipalName or servicePrincipalName in Active Directory, but it is only because it is enforced by management tools, such as Active Directory Users and Computers (ADUC) and the setspn utility, and not by the underlying directory service.

For most environments, this should be a nothing-burger. Most external tools perform this check beforehand and the setspn -S switch has been recommended for more than a decade. As the article points out, non-unique servicePrincipalNames or userPrincipalNames just don’t work.

The article claims that it “is not practical without writing extensive scripting to enumerate all servicePrincipalNames (SPNs) and userPrincipalNames (UPNs) from the default domain and correlate to find duplicates.” I disagree. Both should be relatively straightforward. Caveat: With recent disclosures of privilege escalation exploit involving SPNs, you may want to alert your IT security team as their defense tools may sound the alarm when they identify a wildcard query using servicePrincialName=*.

Just be aware that unlike the single-valued userPrincipalName, the servicePrincipalName object is multivalued and each domain-connected computer typically registers at least four.

This PowerShell snippet will get all the servicePrincipalNames in the default domain.

This PowerShell snippet will get all the userPrincipalNames associated with all objects in the default domain.

If you need assistance modifying these snippets to search an entire forest or specific domain, feel free to email me at michael.liben@oxfordcomputergroup.com.

Read Part 1 of this blog series here.

If your organization needs assistance with Active Directory, our expert team can help! Contact us here.